[Full-disclosure] Simple Machines Forum (SMF) <= 2.0.5 - multiple vulnerabilities
According to http://simplemachines.org/community/?topic=509417#msg3592194 Simple Machines Forum <= 2.0.5 (but > 1.1.*) is vulnerable to one or more (currently undocumented) security issues. The changes between v2.0.4 and 2.0.5 can be reviewed at http://custom.simplemachines.org/upgrades/index.php?action=upgrade;file=smf_patch_2.0.5.tar.gz;smf_version=2.0.4 This is just a heads up, I haven't tried to look into those in detail. CVE folks: If you'll handle this, please also check the last ones: http://simplemachines.org/community/?topic=496403.0 http://osvdb.org/show/osvdb/92745 http://osvdb.org/show/osvdb/88909 Moritz -- Naumann IT Security Consulting Samariterstr. 16 10247 Berlin Germany ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Drupal core XSS vulnerability
Thanks to Justin for identifying and describing this issue. With a little more detail inline. On Wed, Aug 14, 2013 at 7:33 AM, Justin C. Klein Keane wrote: > Mitigating factors: > - --- > In order to inject arbitrary script malicious attackers must have the > ability to manipulate module .info files on a site filesystem, perhaps > via permissions misconfiguration, It feels unclear to me if the permissions mentioned here are Drupal permissions or others. So, to be clear, this would require server file permission misconfiguration. The info files are placed in the same directories as php code. For this vulnerability to be significant it would require permissions like: -rw-rw-rw- 1 deployuser deployuser243 Jan 7 2013 machine_name.info -rw-rw-r-- 1 deployuser deployuser434 Jan 7 2013 machine_name.install -rw-rw-r-- 1 deployuser deployuser 3802 Jan 7 2013 machine_name.module Or maybe: -rw-rw-r-- 1 deployuser somegroup243 Jan 7 2013 machine_name.info -rw-r--r-- 1 deployuser somegroup434 Jan 7 2013 machine_name.install -rw-r--r-- 1 deployuser somegroup 3802 Jan 7 2013 machine_name.module In the first scenario the attacker would just need a shell on the server. In the second scenario the attacker would need a shell on the server and membership in somegroup. > feels this issue is already public (https://drupal.org/node/637538), > however the public discussion only concerns the development of the > next major release of Drupal - Drupal 8. There is no mention in the > public discussion, of the fact that this issue faces both current > supported release versions (Drupal 7 and Drupal 6) and likely previous > releases. I updated that issue to include Drupal 7 and Drupal 6 mentions. It's true this affects previous releases, but previous releases are explicitly EOL and full of holes that are not documented. * Drupal 5 EOL Announcement: https://drupal.org/node/1027214 * Drupal 4.7 EOL Announcement: https://drupal.org/node/225729 Regards, Greg ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Quick Blind TCP Connection Spoofing with SYN Cookies
Good write up that Jakob and an interesting read. Thanks ,) ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [Security-news] SA-CONTRIB-2013-069 - Password Policy - XSS
View online: https://drupal.org/node/2065387 * Advisory ID: DRUPAL-SA-CONTRIB-2013-069 * Project: Password policy [1] (third-party module) * Version: 6.x, 7.x * Date: 2013-August-14 * Security risk: Moderately critical [2] * Exploitable from: Remote * Vulnerability: Cross Site Scripting DESCRIPTION - This module enables you to specify a certain level of password complexity (aka. "password hardening") for user passwords in Drupal by defining a password policy. When viewing and editing a password policy, the module doesn't sufficiently filter the form text field input and display for the "Password Expiration Warning" field. This vulnerability is mitigated by the fact that an attacker must have a role with the permission "Administer policies" to create and edit password policies. CVE IDENTIFIER(S) ISSUED * /A CVE identifier [3] will be requested, and added upon issuance, in accordance with Drupal Security Team processes./ VERSIONS AFFECTED --- * Password policy 6.x-1.x versions prior to 6.x-1.5. * Password policy 7.x-1.x versions prior to 7.x-1.4. Drupal core is not affected. If you do not use the contributed Password policy [4] module, there is nothing you need to do. SOLUTION Install the latest version: * If you use the Password policy module for Drupal 6.x, upgrade to Password policy 6.x-1.6 [5] * If you use the Password policy 1.x module for Drupal 7.x, upgrade to Password policy 7.x-1.5 [6] Also see the Password policy [7] project page. REPORTED BY - * Justin C. Klein Keane [8] FIXED BY * Mark Shropshire [9] COORDINATED BY -- * Greg Knaddison [10] of the Drupal Security Team CONTACT AND MORE INFORMATION The Drupal security team can be reached at security at drupal.org or via the contact form at http://drupal.org/contact [11]. Learn more about the Drupal Security team and their policies [12], writing secure code for Drupal [13], and securing your site [14]. [1] http://drupal.org/project/password_policy [2] http://drupal.org/security-team/risk-levels [3] http://cve.mitre.org/ [4] http://drupal.org/project/password_policy [5] https://drupal.org/node/2065241 [6] https://drupal.org/node/2065247 [7] http://drupal.org/project/password_policy [8] http://drupal.org/user/302225 [9] http://drupal.org/user/14767 [10] http://drupal.org/user/36762 [11] http://drupal.org/contact [12] http://drupal.org/security-team [13] http://drupal.org/writing-secure-code [14] http://drupal.org/security/secure-configuration ___ Security-news mailing list security-n...@drupal.org Unsubscribe at http://lists.drupal.org/mailman/listinfo/security-news ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [Security-news] SA-CONTRIB-2013-068 - Entity API - Access Bypass
View online: https://drupal.org/node/2065207 * Advisory ID: DRUPAL-SA-CONTRIB-2013-068 * Project: Entity API [1] (third-party module) * Version: 7.x * Date: 2013-August-14 * Security risk: Moderately critical [2] * Exploitable from: Remote * Vulnerability: Access bypass DESCRIPTION - The Entity API module extends the entity API of Drupal core in order to provide a unified way to deal with entities and their properties. The module doesn't sufficiently enforce node access restrictions when checking for a user's access to view a comment associated with a particular node. The vulnerability is mitigated by the fact that it only applies to a user's access to view a comment in a situation where access should be restricted with entity access. The Entity API also does not properly restrict access when displaying selected entities using the Views field or area plugins, allowing users to view entities that they do not have access to. The vulnerability is mitigated by the fact that entities are only improperly exposed when a View has been configured to display them in a field, header or footer of a View. CVE IDENTIFIER(S) ISSUED * /A CVE identifier [3] will be requested, and added upon issuance, in accordance with Drupal Security Team processes./ VERSIONS AFFECTED --- * Entity API 7.x-1.x versions prior to 7.x-1.2 Drupal core is not affected. If you do not use the contributed Entity API [4] module, there is nothing you need to do. SOLUTION Install the latest version: * If you use the Entity API module for Drupal 7.x, upgrade to Entity API 7.x-1.2 [5] Also see the Entity API [6] project page. REPORTED BY - The comment access bypass was reported by: * tanius [7] * Ezra Barnett Gildesgame [8] The Views header/footer access bypass was reported by: * Derek Ahmedzai [9] * Daniel Wehner [10] FIXED BY * Devin Carlson [11] * Jakob Perry [12] * Daniel Wehner [13] * Wolfgang Ziegler [14], the module maintainer COORDINATED BY -- * Klaus Purer [15] of the Drupal Security Team * Greg Knaddison [16] of the Drupal Security Team CONTACT AND MORE INFORMATION The Drupal security team can be reached at security at drupal.org or via the contact form at http://drupal.org/contact [17]. Learn more about the Drupal Security team and their policies [18], writing secure code for Drupal [19], and securing your site [20]. [1] http://drupal.org/project/entity [2] http://drupal.org/security-team/risk-levels [3] http://cve.mitre.org/ [4] http://drupal.org/project/entity [5] https://drupal.org/node/2065197 [6] http://drupal.org/project/entity [7] https://drupal.org/user/2478456 [8] https://drupal.org/user/69959 [9] https://drupal.org/user/167927 [10] https://drupal.org/user/99340 [11] https://drupal.org/user/290182 [12] https://drupal.org/user/45640 [13] https://drupal.org/user/99340 [14] https://drupal.org/user/16747 [15] http://drupal.org/user/262198 [16] http://drupal.org/user/36762 [17] http://drupal.org/contact [18] http://drupal.org/security-team [19] http://drupal.org/writing-secure-code [20] http://drupal.org/security/secure-configuration ___ Security-news mailing list security-n...@drupal.org Unsubscribe at http://lists.drupal.org/mailman/listinfo/security-news ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [Security-news] SA-CONTRIB-2013-067 - BOTCHA - Information Disclosure (potential Privilege Escalation)
View online: https://drupal.org/node/2065057 * Advisory ID: DRUPAL-SA-CONTRIB-2013-067 * Project: BOTCHA Spam Prevention [1] (third-party module) * Version: 7.x * Date: 2013-August-14 * Security risk: Moderately critical [2] * Exploitable from: Remote * Vulnerability: Information Disclosure DESCRIPTION - BOTCHA is a highly configurable non-CAPTCHA spam protection framework. The module includes a debug mode which logs the content of submitted forms including passwords and other sensitive information. An attacker who gains access to the log (i.e. dblog or syslog depending on configuration) could get access to usernames and passwords or other sensitive information. The vulnerability is mitigated by the fact that the debugging level must be set to level 5 or 6 (a high level) and the attacker must gain access to the logs (i.e. "access site reports" permission or access to syslog). If you debug level 5 or 6 enabled on a production site, you should consider expiring passwords and instruct users to change their passwords. CVE IDENTIFIER(S) ISSUED * /A CVE identifier [3] will be requested, and added upon issuance, in accordance with Drupal Security Team processes./ VERSIONS AFFECTED --- * BOTCHA 7.x-1.x versions prior to 7.x-1.6. * BOTCHA 7.x-2.x versions prior to 7.x-2.1. * BOTCHA 7.x-3.x versions prior to 7.x-3.3. Drupal core is not affected. If you do not use the contributed BOTCHA module, there is nothing you need to do. Drupal core is not affected. If you do not use the contributed BOTCHA Spam Prevention [4] module, there is nothing you need to do. SOLUTION Install the latest version: * If you use the 1.x branch of BOTCHA module for Drupal 7.x, upgrade to BOTCHA 7.x-1.6 [5] * If you use the 2.x branch of BOTCHA module for Drupal 7.x, upgrade to BOTCHA 7.x-2.1 [6] * If you use the 3.x branch of BOTCHA module for Drupal 7.x, upgrade to BOTCHA 7.x-3.3 [7] Also see the BOTCHA Spam Prevention [8] project page. REPORTED BY - * Rob Hess [9] FIXED BY * Dmitry Danilson [10] the module maintainer COORDINATED BY -- * Greg Knaddison [11] of the Drupal Security Team CONTACT AND MORE INFORMATION The Drupal security team can be reached at security at drupal.org or via the contact form at http://drupal.org/contact [12]. Learn more about the Drupal Security team and their policies [13], writing secure code for Drupal [14], and securing your site [15]. [1] http://drupal.org/project/botcha [2] http://drupal.org/security-team/risk-levels [3] http://cve.mitre.org/ [4] http://drupal.org/project/botcha [5] https://drupal.org/node/2064781 [6] https://drupal.org/node/2064783 [7] https://drupal.org/node/2064785 [8] http://drupal.org/project/botcha [9] http://drupal.org/user/507864 [10] http://drupal.org/user/1209848 [11] http://drupal.org/user/36762 [12] http://drupal.org/contact [13] http://drupal.org/security-team [14] http://drupal.org/writing-secure-code [15] http://drupal.org/security/secure-configuration ___ Security-news mailing list security-n...@drupal.org Unsubscribe at http://lists.drupal.org/mailman/listinfo/security-news ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] SQL Injection vulnerability in Soltech.CMS
Hello list! There is SQL Injection vulnerability in Soltech.CMS. This is commercial CMS. - Affected products: - Vulnerable are Soltech.CMS v 0.4 and previous versions. - Affected vendors: - Soltech http://soltech.com.ua -- Details: -- SQL Injection (WASC-19): http://site/index.php?level_path=%27%20or%20version()=5%23 Timeline: 2013.06.05 - announced at my site. 2013.06.07 - informed developers about the first part of vulnerabilities. 2013.07.14 - informed developers about the second part of vulnerabilities. 2013.08.13 - disclosed at my site (http://websecurity.com.ua/6550/). Best wishes & regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Drupal core XSS vulnerability
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NB: Before anyone gets their panties in a twist read the whole
disclosure, this isn't the end of the world, sky-is-falling
vulnerability you might be looking for, but I do believe it is
serious. TLDR: check your .info files!
Vulnerability Report
Author: Justin C. Klein Keane
Reported: 7 August, 2013
Description of Vulnerability:
- -
Drupal (http://drupal.org) is a robust content management system (CMS)
written in PHP and MySQL. Drupal core suffers from multiple
persistent (stored) cross site scripting (XSS, or arbitrary script
injection) vulnerabilities because the core System module, included in
all Drupal sites, fails to sanitize module names and descriptions
provided in module metadata files (identified by their .info
extension) before display in some locations.
Systems affected:
- -
Drupal 7.22 and 6.28 were tested and shown vulnerable. Other versions
are likely affected.
Impact
- --
Attackers can inject arbitrary HTML (including JavaScript) in order to
attack site administrators. This could lead to account compromise
(which could in turn lead to arbitrary PHP code execution privileges),
or expose administrative users to client side malware attacks.
Mitigating factors:
- ---
In order to inject arbitrary script malicious attackers must have the
ability to manipulate module .info files on a site filesystem, perhaps
via permissions misconfiguration, or to manipulate these files in
modules before they are deployed to a site, such as with the Features
module (https://drupal.org/project/features). It would be quite rare
to be able to manipulate a .info file without the ability to
manipulate actual PHP code contained in modules. However, malicious
script contained in .info files would likely be overlooked in any
security audit since these files are assumed to be inert text files,
devoid of any scripting, markup, or executable code. It is worth
noting that the content of .info files is sanitized for display in
some locations, but this treatment is not uniform. Thus the
likelihood of an attack via this vector is LOW, but the impact is
extremely high, and the attack would likely escape notice by most
automated and manual security countermeasures.
Proof of Concept Exploits:
- -
1. Install Drupal 7-22
2. Create a new directory in the /sites/all/modules named "evil"
3. Create the file evil.info in the /sites/all/modules/evil directory
to include the following content:
name = alert('evil name');
description = alert('evil desc');
core = 7.x
package = Other
version = 7.x-1.0
project = evil_feature
dependencies[] = system
4. Create the file evil.module in the /sites/all/modules/evil
directory to include the following contents:
$info['name'],
+'#markup' => check_plain($info['name']),
);
$form['description'] = array(
- -'#markup' => t($info['description']),
+'#markup' => t("@desc", array('@desc' => $info['description'])),
);
$form['version'] = array(
'#markup' => $info['version'],
Vendor Response:
-
The Drupal Security Team considers this vulnerability worthy of public
discussion. The team points out that an attacker able to manipulate a
.info file would likely be able to manipulate PHP code found in other
files in the same directory. Furthermore, the Drupal Security Team
feels this issue is already public (https://drupal.org/node/637538),
however the public discussion only concerns the development of the
next major release of Drupal - Drupal 8. There is no mention in the
public discussion, of the fact that this issue faces both current
supported release versions (Drupal 7 and Drupal 6) and likely previous
releases.
- --
Justin C. Klein Keane
http://www.MadIrish.net
Any digital signature on this message can be confirmed using
the GPG key at http://www.madirish.net/gpgkey
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iPwEAQECAAYFAlILhzQACgkQkSlsbLsN1gDJjgb+MFQ5xee1G5zfZ25T2jpMLztb
Y/UFjB068iAytm6ogTg35Iyz9y/aBNapPvVLCMRy8rmYtywJIpORy6Jxnwsyxxq+
Lkf3SeXXGHG1V7gDSVtt+H+SDtpRS3aqYigYVb+Ia6tlkfb2IR7dBdUWCVuT3789
Qf2NPbVqdxvn2xHVGItnto1qKfqd4AqssATtBoe/hdE/ti7QOgQmxg7yA9fi4KBU
uhdd6Skq8ZLsbacFSA45jpT9QRJPnQt6tWWiF7ePU/e/xZjrIUZZWHDHTHo8ntpk
fQVjZlI7cOwojrP9sd0=
=rilD
-END PGP SIGNATURE-
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Quick Blind TCP Connection Spoofing with SYN Cookies
Advisory location: http://www.jakoblell.com/blog/2013/08/13/quick-blind-tcp-connection-spoofing-with-syn-cookies/ Quick Blind TCP Connection Spoofing with SYN Cookies Abstract: TCP uses 32 bit Seq/Ack numbers in order to make sure that both sides of a connection can actually receive packets from each other. Additionally, these numbers make it relatively hard to spoof the source address because successful spoofing requires guessing the correct initial sequence number (ISN) which is generated by the server in a non-guessable way. It is commonly known that a 32 bit number can be brute forced in a couple of hours given a fast (gigabit) network connection. This article shows that the effort required for guessing a valid ISN can be reduced from hours to minutes if the server uses TCP SYN Cookies (a widely used defense mechanism against SYN-Flooding DOS Attacks), which are enabled by default for various Linux distributions including Ubuntu and Debian. I. Repetition of TCP Basics A TCP Connection is initiated with a three-way handshake: SYN: The Client sends a SYN packet to the server in order to initiate a connection. The SYN packet contains an initial sequence number (ISN) generated by the client. SYN-ACK: The server acknowledges the connection request by the client. The SYN-ACK Packet contains an ISN generated by the server. It also confirms the ISN from the client in the ack field of the TCP header so that the client can verify that the SYN-ACK packet actually comes from the server and isn't spoofed. ACK: In the final ACK packet of the three-way handshake the client confirms that it has received the ISN generated by the server. That way the server knows that the client has actually received the SYN-ACK packet from the server and thus the connection request isn't spoofed. After this three-way handshake, the TCP connection is established and both sides can send data to each other. The initial sequence numbers make sure that the other side can actually receive the packets and thus prevent IP spoofing given that the attacker can't receive packets sent to the spoofed IP address. Since the initial sequence numbers are only 32-bit values, it is not impossible to blindly spoof a connection by brute-forcing the ISN. If we need to send 3 packets to the server (one SYN packet to initiate the connection, one ACK packet to finish the three-way handshake and one payload packet), we will have to send 3*2^32 packets per successfully spoofed connection at an average. Given a packet rate of 300,000 packets per second (which can easily be achieved with a gigabit connection), sending this packets requires some 12 hours. One long-known weakness of the original TCP protocol design is that an attacker can spoof a high number of SYN packets to a server. The server then has to send (and maybe even retransmit) a SYN-ACK packet to each of the spoofed IP addresses and keep track the half-open connection so that it can handle an ACK packet. Remembering a high number of bogus half-open connections can lead to resource exhaustion and make the server unresponsive to legitimate clients. This attack is called SYN Flooding and it can lead to DOS even if the attacker only uses a fraction of the network bandwidth available to the server. II. Description of the SYN Cookie approach In order to protect servers against SYN-Flooding attacks, Daniel J. Bernstein suggested the technique of TCP Syn Cookies in 1996. The main idea of the approach is not to keep track of incoming SYN packets and instead encode the required information in the ISN generated by the server. Once the server receives an ACK packet, he can check whether the Ack number from the client actually matches the server-generated ISN, which can easily be recalculated when receiving the ACK-packet. This allows processing the ACK packet without remembering anything about the initial SYN request issued by the client. Since the server doesn't keep track of half-open connections, it can't remember any detail of the SYN packet sent by the client. Since the initial SYN packet contains the maximum segment size (MSS) of the client, the server encodes the MSS using 3 bits (via a table with 8 hard-coded MSS values). In order to make sure that half-open connections expire after a certain time, the server also encodes a slowly-incrementing (typically about once a minute) counter to the ISN. Other options of the initial SYN packet are typically ignored (although recent Linux kernels do support some options by encoding them via TCP Timestamps [1]). When receiving an ACK packet, the kernel extracts the counter value from the SYN Cookie and checks whether it is one of the last 4 valid values. The original approach of Bernstein [2] only encodes the counter and the MSS value in the first 8 bits of the ISN thus leaving only 24 bits for the cryptographically generated (non-guessable) value which needs to be guessed for spoofing a
Re: [Full-disclosure] CALEA & Re: XKeyscore
Now that you have kindly explained your point, i must say This has been a wonderful discussion. It has certainly shed some additional light into how CALEA can be used domestically for other functions not part of its intended purpose. Now that I have basked in the limelight of my 5 minutes of fame... I will diminish, and crawl back to my cave to admire the glistening shine of my precious. If someone can sing me a song, a lullaby if you will, that briefly touches on how the hell XK can claim they will decrypt VPN user traffic... that would be just dandy. Does or Does not the NSA have the keys to decrypt common 3DES traffic?___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
